软件架构学习小结文档格式.docx

软件架构学习小结文档格式.docx

《软件架构学习小结文档格式.docx》由会员分享，可在线阅读，更多相关《软件架构学习小结文档格式.docx（24页珍藏版）》请在冰豆网上搜索。

领导才能：

能够推动各个团队的技术进展，并能在压力下作出关键性的决策然后将其贯彻到底。

要提高效率，构架设计师和项目经理必须紧密协作。

构架设计师主要负责解决技术问题，项目经理主要负责解决行政管理问题。

构架设计师必须有权在技术问题上作出决定。

沟通：

能够赢得他人的信任，以对其进行说服、激励和指导。

构架设计师不能靠命令进行领导，而必须要赢得项目中其他人员的赞同。

为了提高效率，构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。

以目标为中心、积极主动：

不懈地追求成效。

构架设计师是推动项目发展的技术动力，而不是空想家。

在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。

构架设计师只有将注意力集中在该做的事情上，才能在项目中取得成功。

专业：

精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）。

具备系统设计员的所有技能，但涉及面更广、抽象级别更高。

二、软件架构、架构模式、参考模型、参考架构

1、对于软件架构定义有很多种，通用的定义是：

某个软件或计算机系统的软件架构是该系统的一个或多个结构，他们由软件元素，这些元素的外部可见属性以及这些元素之间的关系组成。

这里所说的某个元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征、错误处理、共享资源的使用，等等。

其他的定义包括：

架构是一种高层设计。

架构是系统的总体结构。

架构是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构。

架构是组件和连接器。

2、架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。

3、参考模型是一种考虑数据流的功能划分。

4、参考架构是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功能）及元素之间数据流上的参考模型。

5、软件架构、架构模式、参考模型、参考架构之间的关系：

软件结构

关系

适用环境

分解

是一个子模块；

与之共享秘密

资源分配、项目结构化和规划；

信息隐藏、封装；

配置控制

使用

要求正确出现

设计子集；

设计扩展

分层

要求正确的出现、使用服务、提供抽象

增量式开发；

在“虚拟机”可移植性之上实现系统

类

是一个实例；

共享访问方法

在面向对象的设计系统中，从一个公共的模版中产生快速的、相近的实现

客户机-服务器

与之通信；

依赖于

分布式操作；

关注点分离；

性能分析；

负载平衡

进程

与之并发运行、可能会与之并发运行；

排除；

优先于等

调度分析；

性能分析

并发

在相同的逻辑线程上运行

确定存在资源争用，线程可以交叉、连接、被创建或被杀死的位置

共享数据

产生数据；

使用数据

性能；

数据完整性；

可修改性

部署

分配给；

移植到

性能、可用性、安全性分析

实现

存储在

配置控制、集成、测试活动

工作分配

分配到

项目管理、最佳利用专业技术、管理通用性

注：

在＜Pattern-OrientedSoftwareArchitecture（面向模式的软件体系架构）＞中首次提出了8种体系结构模式：

层（Layers）、管道和过滤器（PipesandFilters）、黑板（Blackboard）、代理者（Broker）、模型-视图-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。

6、架构定义中指出系统由多种结构构成的，下面列出一些常见的结构。

7、质量属性

系统从设计、实现到部署的整个过程中考虑质量属性的实现。

质量属性包括下列三类：

（1）、系统的质量属性。

（可用性、可修改性、性能、安全性、可测试性和易用性）

（2）、受架构影响的商业属性。

（上市时间、成本和收益、所希望的系统生命期的长短、目标市场、推出计划、与老系统的集成）

（3）、与架构本身相关的一些质量属性。

（概念完整性、正确性与完整性、可构建性）

六个质量属性的战术列表：

三、设计架构

几乎在我们遇到的所有成功的面向对象系统中都具有但失败的系统中缺少的两个特性是：

存在一个强大的构架构想，应用管理良好的迭代式增量开发周期。

功能、质量和商业需求的某个集合“塑造”了构架。

我们把这些塑造需求称为“构架驱动因素”。

构架设计必须按需求分析进行，但不需要在需求分析完成后在开始构架设计。

实际上，在确定了关键的构架驱动因素后，就可以开始构架设计了。

当设计了构架的足够多的部分后，就可以开始开发骨架系统了。

该骨架系统在上面进行迭代开发（以及其在任何一个点交付的能力）的框架。

组织结构对构架产生影响。

属性驱动的设计（ADD）是一个用于设计构架以满足质量需求和功能需求的方法。

ADD把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。

ADD步骤：

（1）选择要分解的模块。

（2）根据这些步骤对模块进行求精。

对需要进一步分解的每个模块重复上述步骤。

在设计架构过程中可以重用架构，重用一些技术以方便来实现架构与设计。

高层重用技术分类

高层重用

设计模式

框架

软件架构

架构风格

架构设计风格

架构框架

架构平台

设计模式：

使用相互通信的类和对象可为常见的设计问题提供通用的解决方案。

为了帮助用户掌握模式的概念并有效地设计模式，我通常为设计模式的描述提供一个带有比喻性的抽象。

常见的设计模式有：

Fvacade（外观模式），它为子系统中的一系列动作提供一个统一接口；

Ovbserver（观察者模式），具体的设计模式内容参考GOF23设计模式。

框架：

提供一组相互协作的类及运行时对象，用于生成某些特定领域的应用软件。

我们可以根据特定应用的需求方便地对框架中的抽象和类进行定制，以重用框架的设计和代码。

软件架构：

编制软件也称为架构软件。

一个可操作的软件内部应具有某种形式的架构。

软件架构技术中可重用的实体可以进一步地分为4类：

架构风格、架构设计风格、架构框架、架构平台。

架构风格给出了精心设计的软件全局的通用形态。

例如，Shaw和Garlan提出了7种架构风格：

管道和过滤器、面向对象的组织、隐式调用、分层系统、仓库、状态机、解释器，及过程控制。

架构设计风格给出了软件架构的设计方法论。

Shaw将众多的设计风格分类为如下8种：

功能分解、数据流、面向对象、状态机、面向事情、过程控制、数据结构及决定表。

架构框架是来为详细而完整的框架，它为开发特定领域的应用系统使用了一系列多种架构设计风格。

一个采用了某些设计风格的软件架构制品，只有当它具有完备的文档，并具备包含一个特定的应用领域所需要的充分灵活性时才可以作为软件框架来重用。

架构平台提供了一个可以适应多种应用系统的灵活的底层结构，架构平台的设计目的即是为了应用软件的互操作性提供硬件平台及操作系统平台无关环境。

我们可以将它们用做底层结构，以促进对象级的协作和重用。

对象管理组织（OMG）的通用对象请求代理体系结构（CommonObjectRequestBrokerArchitecture，CORBA）即是一个示例。

四、架构评估方法

软件构架的评估方法：

SAAM和ATAM。

这里只详细说明ATAM方法。

ATAM一种进行构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。

在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表（以场景的方式），并说明与实现每个高优先场景相关的构架决策。

然后，把这些决策确定为有风险决策或无风险决策，以找到构架中任何存在问题的地方。

ATAM不是需求评估。

ATAM不是代码评估。

ATAM不包括实际的系统测试。

ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。

这些风险包含在敏感点和权衡中。

ATAM活动的4个阶段：

在第0阶段（合作关系和准备）确定细节：

人员名单，时间，地点；

评估小组获取资料并进行初步了解分析。

第1阶段，评估阶段，决策者参与，小组开始信息收集与分析；

耗时约1周。

1～2周中断期，评估小组进一步以非正式方式了解构架。

第2阶段，评估阶段，涉众参与，分析继续；

约2天。

第3阶段，后续阶段，生成最终报告，进行评估活动总结；

1周。

评估阶段的步骤：

第1步：

ATAM方法的表述。

评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局。

第2步：

商业动机的表述。

决策者介绍系统商业动机、重要功能、各种限制（任何相关的技术、管理、经济和政治限制）、商业目标和上下文、主要的涉众、驱动因素等。

第3步：

构架的表述。

首席设计师或架构小组介绍构架，技术限制、所用模式等。

第4步：

对构架方法进行分类。

评估小组利用所有已知信息对构架方法进行分类。

第5步：

生成质量属性效用树。

生成质量属性效用树，捕获详细的需求信息，为每个场景分配一个级别，如（高，中），前者为重要度，后者为实现难易度，重点放在（高，高）的场景；

此处场景具备刺激、环境、响应三要素就可以了。

第6步：

分析构架方法。

评估小组分析所有重要场景，设计师解释如何支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点。

经过一段中断期，第2阶段开始，此时涉众开始参与；

首先仍然需要一个对ATAM方法的介绍，并使涉众了解已有的成果。

第7步：

集体讨论并确定场景的优先级。

集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；

该过程可能产生新的场景；

使用“有限票数法”投票确定每个场景的优先级——此处不考虑实现难度。

第8步：

分析新的高优先级的场景，构架师解释构架是怎么满足各场景的。

第9步：

结果表述。

总结评估结果，评估负责人展示该结果。

五、软件架构风险管理

1、如何识别软件架构的风险

（1）需求的不断变化

（2）架构师对于技术理解不足

（3）缺乏对行业的研究

（4）经验不足

（5）创造性的架构比重比较重

（6）没有形成一套构架的规范

（7）架构可执行性差

2、如何规避软件架构风险

固化需求

完善的业务原型

完整架构规范

验证架构的可执行性

80%的经验架构+20%的创新架构

六