系统架构师笔记(二)

标签: 系统 架构师 笔记 | 发表时间:2013-11-07 21:55 | 作者:cl05300629
出处:http://blog.csdn.net

今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享。

七、架构权衡分析法:ATTM(Architecture Tradeoff Analysis Method)
评价软件架构的一种综合全面的方法。这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标。
1、ATAM参与人员
评估小组、项目决策者、构架涉众
2、ATAM的结果
ATAM评估将产生至少如下结果:一个简洁的构架表述;表述清楚的业务目标;用场景集合捕获的质量需求;构架决策到质量需求的映射;所确定的敏感点和权衡点集合;有风险决策和无风险决策;风险主题的集合。
3、ATAM的目标
分析多个质量属性间的关系,属性间可能存在冲突,需要权衡取舍。按照质量属性需求,评价体系结构设计。
4、ATAM的阶段
关系和准备:参与人员为评估小组负责人和主要的项目决策者,根据要求进行,大概需要几周的时间。
评估:参与人员为评估小组和项目决策者,一般需要1周,还有2~3周的中断时间。包括以下步骤:ATAM方法的表述;商业动机的表述;构架的表述;对构架方法进行分类;生成质量属性效用树;分析构架方法。
评估(继续):参与人员为评估小组、项目决策者以及涉众,一般需要2天。包括以下步骤:集体讨论并确定场景的优先级;分析构架方法;结果的表述;
后续工作:参与人员为评估小组和评估客户,一般需要一周。
八、DSSA(Domain Specific Software Architecture)特定领域软件架构
    特定领域软件架构师在一个特定应用领域为一组应用提供组织结构参考的标准软件架构。实施DSSA的过程包括一系列基本活动,其中领域设计活动的主要目的是获得DSSA,该活动参与人员中,领域专家的主要任务是提供关于领域中系统的需求规约和实现的知识。

    DSSA与软件体系结构风格是从不同角度出发研究问题的两种结果,前者从问题域出发,后者从解决域出发。

    DSSA只对某个领域进行专家知识的提取、存储、组织,但可以同时使用多种软件体系结构风格;而在某个软件体系结构风格中进行专家知识组织时,可以将提取的公共结构和设计方法扩展到多个应用领域。

    DSSA通常选用一个或多个适合所研究的领域的体系结构风格,并设计一个该领域专用的体系结构分析设计工具。但该方法提取的专家知识只能应用于一个较小的范围--所在领域。一个领域的

    DSSA及其工具在另一个领域中是不适应的,或不可以重用的。

    体系结构风格避免设计到特定的应用领域或背景,所提取的知识比DSSA提取的知识应用范围要广。但在一个特定领域中,正是由于体系结构风格对领域知识、领域背景的忽略,使其在一个具体领域的开发中的作用并不比DSSA要大。

    DSSA与体系结构风格是互为补充的两种技术。

九、常见算法
1、对称算法:DES(Data Encryption Standard,数据加密标准)、IDEA(International Data Encryption Algorithm国际数据加密算法)
2、不对称算法:RSA、ECC
3、散列函数(摘要算法):MD5(Message Digest 5)
4、数字签名:RSA、ElGamal、Fiat-Shamir、DSS/DSA、椭圆曲线
5、数字水印:空域算法、变换域算法、压缩域算法、NEC算法、生理模型算法等
6、安全协议:Ipsec(跨越网络边界的通信)、Secure Socket Layer:SL协议(计算机之间的整个会话进行加密)、RGP(Pretty Good Privacy 电子邮件在Internet上的通信安全)
十、数据备份
1. 完全备份,所需时间最长,但恢复时间最短,操作最方便可靠。
2. 差异备份,备份上一次的完全备份后发生变化的所有文件。备份时间较长,占用空间较多,恢复时间
较短。
3. 增量备份,上一次备份后,所有发生变化的文件。备份时间较短,占用空间较少,恢复时间较长。
4. 按需备份。有很好的选择性。
十一、测试方法
1、恢复测试:检测系统的容错能力。
2、安全性测试:检测系统的安全机制。
3、强度测试:系统在异常情况下的承受能力的测试,是检测系统在极限状态下运行,性能下降的幅度是都在允许的范围内。
4、性能测试:检测系统是否满足系统设计方案说明书对性能的要求。
5、可靠性测试:平均失效间隔时间(mean time between failures)是否超过了规定的时限、因故障而停机时间MTTR(mean time to repairs)在一年中不应超过多少时间。
6、安装测试:检测在安装过程中是否有误、是否容易操作。
7、确认测试:α测试(开发阶段)和β测试(实际使用阶段)
十二、 ABSD(Architecture Based Sofaware Development)基于软件架构的设计
强调由商业、质量和功能需求的组合驱动软件架构设计。强调采用视角和试图来描述软件架构,采用用例和质量属性场景来描述需求。
十三、RUP软件开发
RUP软件开发生命周期是一个二维的软件开发模型,其中有9个核心工作流,分别是:业务建模、需求、分析与设计、实现、测试部署、配置与变更管理、项目管理以及环境。
RUP把软件开发生存周期划分为多个循环,每个循环生成产品的一个新的版本,每个循环依次由4个连续的阶段组成,每个阶段完成确定的任务。这4个阶段分别为:
1、初始阶段:定义最终产品试图和业务结构,并确定系统范围;
2、细化阶段:设计及确定系统的体系结构,制定工作计划及资源要求;
3、构造阶段:构造产品并继续演进需求、体系结构、计划直至产品提交;
4、移交阶段:把产品提交各用户使用。
十四、数据流图和流程图
数据流图作为一种图形化工具,用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程,描述处理过程的控制流。
两者的区别:
1、数据流图中的处理过程可并行;流程图在某个时间点只能处于一个处理过程。
2、数据流图展示系统的数据流;流程图展示系统的控制流;
3、数据流图展现全局的处理过程,过程之间遵循不同是计时标准;流程图中处理过程遵循一直的计时标准;
4、数据流图适用于系统分析中的逻辑建模阶段;流程图适用于系统设计中的物理建模阶段。

高质量数据流图设计时考虑的三个原则:
1、复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子,这样就可以单独考察每一个DFD。如果要了解某个过程更加详细的信息,可以跳转到该过程的下一层;如果要知道一个DFD如何与其他DFD相关联,可以跳转到上一层的DFD记性考查。
2、接口最小化原则。接口最小化是复杂性最小化的一种具体规则,在设计模型时,应使得模型中各个元素之间的接口数或连接数最小化。
3、数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别?是否存在有数据流出但没有相应的数据流入的加工?是否存在有数据流入但没有相应的数据流出的加工?
出处: http://blog.csdn.net/cl05300629/article/details/14450285 作者:伫望碧落

作者:cl05300629 发表于2013-11-7 13:55:22 原文链接
阅读:116 评论:0 查看评论

相关 [系统 架构师 笔记] 推荐:

系统架构师笔记(二)

- - CSDN博客Web前端推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 七、架构权衡分析法:ATTM(Architecture Tradeoff Analysis Method). 评价软件架构的一种综合全面的方法. 这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标.

系统架构师笔记(一)

- - CSDN博客架构设计推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 1、性能:系统的响应能力,即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数. 架构设计策略:增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等).

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

对大宋下一代系统软件架构师的七个期望

- joyoner - 弯曲评论
有诗云:人之老,其言真;人之去;其行善. 系统软件设计是软件系统的皇冠中的宝石. 在系统软件,特别是通信系统软件的设计上,有没有一些可以提炼的方法论. 今身处幽州(北平),心在大宋. 谈谈我对大宋年轻一代的系统软件工程师的期望. 年轻人都以为有些事情需要粗,有些事情需要厚. 系统软件一定要越细越好;越薄越好.

推荐系统的学习笔记

- - CSDN博客综合推荐文章
一直以来对推荐系统的学习和理解来自一些机器学习书中简单介绍(如《集体智慧编程》和《机器学习实战》)和自己网上搜的一些资料. 而当被问及对推荐系统的改进和理解,发现自己对推荐系统所知甚少,除了知道几个常用的算法外,根本没有更深入的理解,更别提改进了. 本篇博客为学习《推荐系统》一书的读书笔记,记录了常见的推荐算法和其思想.

腾讯海外计费系统架构演进 | TEGer在全球架构师峰会

- -
作者简介:abllen,2008年加入腾讯,一直专注于腾讯计费平台建设,主导参与了腾讯充值中心、计费开放平台、统一计费米大师等项目,见证了米大师从0到1,业务营收从PC到移动多终端再到全球化的跨越过程. 目前专注于跟团队一起为腾讯业务提供稳定高效安全的全球化个人和企业市场计费服务. 经过海外3年建设,腾讯Midas(米大师)计费逐步构建起了一个分布式的全球计费系统,来助力公司及业内产品计费扬帆出海,走向深蓝.

分布式系统 读书笔记(二)数据平滑迁移

- - 企业架构 - ITeye博客
在开始进行数据迁移时,记录增量的日志,在迁移结束后,再对增量变化进行处理. 在最后,可以把要迁移的数据的写暂停,保证增量日志都处理完毕后,再切换规则,放开所有的写,完成迁移工作. 我们希望根据id去模把上面这个表 划分到两个数据库中,  也就是id  mod 2 为0的还在原数据库  为1的在新库中.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

架构师图谱(上)

- - DockOne.io
“架构师图谱”是一个很宏大的命题,特别是优秀的架构师自身也是“由点到面再到图”,一点点成长积累起来,尝试写这篇文章的目的更多的是结合自身的一些架构、研发、管理经验对现阶段做一个复盘总结,所以这里更偏向于后端图谱,依赖于开源技术、云原生或者其他第三方服务. 这里会重点介绍一些技术栈、设计理念以及适应场景,这些可以作为我们选型时的依据.

分布式系统 读书笔记(三)跨库查询的问题和及解决

- - 企业架构 - ITeye博客
如果一个查询涉及多个库或者多张分表 结果该如何处理. 1.排序,即多个来源的数据查询出来以后,在应用层进行排序的工作. 查出来如果是已经排序号的,则对多路进行归并排序否则就要进行一个全排序. 2.函数处理,即使用Max,Min,Sum,Count 等函数对多个数据来源的值进行相应的函数处理. 3.求平均值,从多个数据来源进行查询时,需要把SQL改为查询SUM和Count,然后对多个数据来源的Sum求和,count求和后,计算平均值,这是需要注意的地方.