体系结构复习整理：一些可能有用的概念.docVIP

体系结构的概念 表示软件高层架构，包括静态和动态属性： 指该系统的结构，包括软件组件，及其外部可见属性，以及组件间的关系 组件： 是一个构造块，通过接口描述其服务的计算或数据仓库的集合。常见组件：类，函数，模块，包，层，文件，数据库，客户端，服务器 组件是逻辑元素，粒度可自由控制，而对象是实现元素，粒度较小，且两者抽象程度不同。 如何定义组件： 组件的函数和职责，以及接口必须被定义 核心设计类需要被定义：核心类实现组件主要功能，实现，但是只有类的Skeleton被提供定义，具体内容需要设计阶段给出 ： 允许组件间交互的构造块（不是简单的接口），降低组件间的耦合，同时连接互相不兼容的组件 连接器包括显式的和隐式的，有时仅仅是一个通道，有时包括自己的逻辑和复杂度 常见连接器： （Implicit）事件，C/S中间件，消息和消息总线，共享变量，过程调用（本地、远程），管道， （Explicit）代理，适配器 关注点 ——在开发者和其他涉众间提供一个共享的精神模型同时面向问题域和解空间，保证需求可以追踪到实现 是客户的代理，由客户的需求提炼而来不同的涉众关注系统的不同方面，软件架构使得对于一个大且复杂系统的不同关注可以被表达、协商达成一致，从而便于管理 表现功能和非功能需求如何被满足 质量的种类： 系统质量：availability, modifiability, performance, security, testability, usability. 商业质量：投放市场的时间，投入回报，计划周期，目标市场，首次展出计划，遗留系统整合 建筑质量：观念一致性，正确性完整性，可建造性 反映设计决策 往往根据架构师的知识背景实现 建立了软件设计和实现的背景，解释一种方法被采用的根本原因，它有什么影响 结构决策是最基本的决策，改变它将会引起很多连锁的反应 架构定义了实现的约束（组件分解，外部可见特性和接口）限定了一个系统的质量属性决定了开发人员的结构组成对于系统资源分配的决策约束了实现 使得修改变得容易控制方便于系统原型的演化 1.选择：和风险（用例视图）确定主要层和他们的责任（逻辑视图）分配行为类（逻辑视图）系统，层次，确定接口（执行期）分和并发（部署视图，过程视图）( 实现原型 8体系以上过程具有迭代的特征。1-7关注功能需求。8关注质量需求 通过需求工程，得到明确的用例文档后，依次进行如下活动： 全局分析（用例）： 寻找影响体系结构的Factor：整合方案，技术特征，通用和领域相关硬件的改变，软件技术的改变，资源限制，容易增删特性，容易改变算法，高性能，实时性，可恢复性，错误诊断，多开发和目标平台，体系结构完整性，并发开发，得到原型的成本。（记住几个，全局分析，比如****，****）。 逻辑视图设计 得到一些能解决基本问题的逻辑模块。 构件视图设计 将逻辑模块转化成构件，分层，最后会增加一些构件，或者层。如下 进程视图设计 将构件转化为进程，如果是单进程系统，此过程略去。进程间有些线，表示进程间通信，一般式Message，共享内存或者RPC。 部署视图设计 有了构件和层，决定构件放在哪些机器上。 体系结构分析步骤 目的：弥补规格需求和SA软件体系结构件的gap差距； 重点关注体系结构设计需求（ADR: architecture design requirements）(GA：分析factors 将ADR和软件体系结构的结构化模型同系统解决方案策略模型（SSS: system solution strategies）联系起来(GA：开发策略 用SSS指导体系结构建立：通过指导比较和选择解决方案策略(“4+1”开发过程后：根据SSS给每个视图做决策 支持软件开发过程的其他部分：ADR和SSS对软件开发其他过程有影响。 体系结构分析步骤： Global Analysis——从软件需求规格到软件体系结构的结构化视图的过程 设计和描述系统的结构 利用互补的视图来减少设计和理解体系结构的复杂性 不同视图有不同关注点，并不是系统所有方面都要被同事考虑 Global Analysis. GA产生描述设计决策上下文和规则的文档 标识可能影响体系结构的外部影响因素和关键的需求 分析产生设计体系结构的策略 2a分析因素(constraints and quality) Three (3) step procedure Step 1：识别可能影响系统体系结构的需求，可以参考SRS，但是不全面 产品因素：质量需求 组织因素：业务质量 技术因素：系统和业务质量 Step 2:描述因素和其灵活性，可变性 Descriptions, flexibility, changeability Step3:分析factor的影响