软件架构学习小结.docx
- 文档编号:3323713
- 上传时间:2022-11-21
- 格式:DOCX
- 页数:26
- 大小:178.24KB
软件架构学习小结.docx
《软件架构学习小结.docx》由会员分享,可在线阅读,更多相关《软件架构学习小结.docx(26页珍藏版)》请在冰豆网上搜索。
软件架构学习小结
软件架构设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单。
本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描述了解软件架构的含义和怎样设计软件架构。
一、软件架构师的职责
架构师分为以下几大类:
业务架构师、主题领域架构师、技术架构师、项目架构师(J2EE架构师、.NET架构师等)、系统架构师。
1、架构师的职责主要体现
架构师的职责就是设计一个公司系统的基础架构,并提供关于怎样建立和维护系统的指导方针。
具体来讲,架构师的职责主要体现在以下几方面:
1)、负责公司系统的架构设计、研发工作。
2)、承担从业务向技术转换的桥梁作用。
3)、协助项目经理制定项目计划和控制项目进度。
4)、负责辅助并指导系统分析开展设计工作。
5)、负责组织技术研究和攻关工作。
6)、负责组织和管理公司内部的技术培训工作。
7)、负责组织及带领公司内部员工研究与项目相关的新技术。
8)、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。
9)、理解系统的业务需求,制定系统的整体框架(包括、技术框架和业务框架)。
10)、对系统框架相关技术和业务进行培训,指导开发人员开发。
并解决系统开发、运行中出现的各种问题。
2、构架设计师必须具备的技能
经验:
既包括在问题领域的经验(通过彻底了解需求),也包括在软件工程领域的经验。
对于一个构架团队,这些素质要求可由各团队成员来分别承担,但其中至少要有一名构架设计师能够把握项目的全局。
领导才能:
能够推动各个团队的技术进展,并能在压力下作出关键性的决策然后将其贯彻到底。
要提高效率,构架设计师和项目经理必须紧密协作。
构架设计师主要负责解决技术问题,项目经理主要负责解决行政管理问题。
构架设计师必须有权在技术问题上作出决定。
沟通:
能够赢得他人的信任,以对其进行说服、激励和指导。
构架设计师不能靠命令进行领导,而必须要赢得项目中其他人员的赞同。
为了提高效率,构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。
以目标为中心、积极主动:
不懈地追求成效。
构架设计师是推动项目发展的技术动力,而不是空想家。
在其职业生涯中,成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。
构架设计师只有将注意力集中在该做的事情上,才能在项目中取得成功。
专业:
精通构架设计的理论、实践和工具,并掌握多种参考构架、主要的可重用构架机制和模式(例如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%的创新架构
六、实用软件体系结构
本部分是提供实用的指南和技术,以更快地得到好的系统结构设计。
我们的哲学是不应该致力于设计理想化的系统结构,而是应该仔细地评估和权衡所有技术、市场、人员、成本方面的问题,从而获取一个好的解决方案。
4种视图+全局分析
1、4种视图
1)、一个软件体系结构有4种截然不同的视图:
概念视图、模块视图、执行视图、代码视图。
使用这个4种视图提供了一种设计软件系统结构的系统化方法,帮助架构师设置优先级,分析权衡,并保证没有缺漏。
2)、不同视图强调的不同工程关注点:
在概念视图中,问题和解决方案主要通过领域术语来考虑的。
对于特定的软件及硬件技术,它们应当是相对独立的。
概念视图的工厂关注点包括:
系统如何满足需求?
商用构件怎样组装成整体,怎样在功能层上与系统的其他部分交互?
领域特定的硬件和软件如何融入系统?
功能是如何被分割并进入产品个版本的?
系统如何与之前版本的产品合并?
它如何支持未来的版本?
如何支持产品线?
如何将由需求或领域中所做的变动引起的影响最小化?
在模块视图中,概念视图中的构件和连接子被映射为子系统和模块。
在这里,架构师强调的是如何用现有的软件平台以及技术实现概念的解决方案。
主要的工程关注点有如下几点:
产品是如何映射到软件平台的?
使用了什么样的系统支持或系统服务?
具体是在什么地方?
怎么支持测试?
如何降低模块间的依赖性?
如何将模块与子系统的复用最大化?
当商用软件、软件平台或标准发生变动时,采用何种技术在封装产品时可以将它们与产品进行隔离?
执行视图描述模块如何映射到运行时平台说提供的元素,以及这些又如何映射到硬件体系结构。
执行视图定义系统的执行时实体及其属性,比如内存使用和硬件分配。
对于执行视图,其工程关注点如下:
系统如何满足性能、恢复及重新配置方面的需求?
如何平衡资源的使用(例如:
负载平衡)?
如何达到必需的并发、复制及分布,而不过度增加控制算法的复杂度?
如何使运行时平台的改变所引起的影响到达最小?
在代码体系结构视图中,架构师决定执行视图中的执行时实体如何映射到部署构件(例如:
可执行构件),决定模块视图中的模块如何映射到源构件,以及部署构件如何从源构件生成。
代码视图中重要的工程关注点如下:
如何降低产品升级的时间和费用?
如何管理产品版本及发布?
如何降低构造时间?
需要什么工具支持开发环境?
如何支持集成与测试?
2、全局分析
全局分析是在定义概念、模块、执行和代码系统结构视图之前进行的,并贯穿整个系统结构的设计过程。
全局分析从识别影响体系结构设计的因素来分成3类:
组织因素、技术因素、产品因素。
组织因素分成5类:
管理;员工技能、兴趣、能力、缺点;过程与开发运行环境;开发进度;开发预算。
技术因素包括:
通用和专用的硬件;操作系统、用户界面、设计模式等软件技术;模版和框架等体系结构技术;图像、数据库、数据格式、算法和技术之类的标准。
产品因素是描述了产品的功能需求、用户可见的特征和产品的性能等质量方面的需求。
比如:
功能特征;用户界面;性能;依赖性;错误监测、报告、修复;服务和价格等。
全局分析是在每一种体系结构设计视图中都要进行的一种行为。
在全局分析过程中建立的问题卡片要用在每一个视图设计的核心设计任务中。
在进行核心设计任务时,做出的决策应当可以返回到全局分析,以增加和修改因素、问题和策略。
总结策略:
问题
应用策略
进度紧迫
复用内部已有的、领域特性构件
购买而不是建立
使元素容易添加和删除
技能不足
避免使用多线程
封装多进程
通用和领域特定硬件的改变
封装领域特定硬件
封装通用硬件
软件技术的改变
使用标准
为外部构件开发产品特定的接口
资源有限
限制活动线程个数
用动态的内部线程见通信联系
易用增加和删除特性
按关联尺度分离构件和模块
特性封装到分开的构件
分离用户交互模块
易用增加和删除采集过程和算法
为图像处理使用灵活的流水线模块
为采集和图像处理引入构件
分离用户交互模块
高吞吐量
把独立的控制线程映射到进程
使用新增的CPU
实时采集性能
从没有临界时间构件中分离出有临界时间的
为模块行为开发准则
灵活的分配模块到进程
使用单速分析来预言性能
使用共享存储进行流水线阶段之间通信
实现恢复
引入操作的恢复模块
把全部数据放到恢复稳定和容易达到的地方
实现诊断
制定一个错误处理策略
减少错误处理的工作
封装诊断构件
使用标准日志服务
体系结构的完整性
保护模块间的继承
分离公共接口构件
并发的开发工作
从源构件中分离开发构件
保护执行视图
采用阶段开发
通过静态库来发布层
限制可使用的采集图像类型
采用适当的抽象开发一个脱机的探测模拟器
使用一个灵活的建立过程
多样性开发和目标平台
分离和封装依赖目标平台的代码
七、特定领域框架
1、框架:
一组类或组件的集合,它们为一个特定领域提供了一组服务和功能。
软件架构的一种实例,它可以使设计的组件具有良好的互操作性。
2、框架分类
根据作用域可以将框架分为系统基础结构框架、中间件集成框架、企业应用框架。
系统基础结构框架是一组可以支持系统基础结构领域的高校可移植框架,例如可以支持操作系统、用户界面、通信及语言处理等,它们通常是由内部开发和使用的,有时也用作供其他应用使用的通用应用。
中间件集成框架的作用是增强软件对基础结构的模块化处理能力、重用能力及扩展能力,从而能够在分布式环境中无缝运行。
中间件集成的例子有OmniBuilder框架和对象请求代理(ORB)。
企业应用框架处理的应用领域很广,如银行、电信、制药等,它们是领域应用的基石。
企业应用中著名的实例有IBMSanFrancisco、企业资源规划(ERP)。
框架类别
框架实例
企业应用框架
Amulet,IBMSanFrancisco,Asyn,LAMA,CORTAN,OMAC框架
中间件集成框架
GUI,QCServicesLayer,PFC/Open,OmniBuilder,PFX,FrameDataFeedHandler框架
系统基础结构框架
ProtocolLayer,ACE,OPTF,DynaFind,ARES,DORB框架
3、框架比较
应用框架调查的比较参数包括操作系统、程序设计语言、领域范畴等。
1)、操作系统:
Windows、UNIX、Linux
2)、语言:
C++、Java
3)、领域范畴
拥有框架最多的两个领域是商务/金融和电信/网络。
框架领域范畴
编号
领域范畴
框架列表
1
通用(无领域)
MaccApp,G++
2
通用GUI
GUI,Amulet,VisiblePropertiesandActionsFramework
3
数据库和数据管理
FRAMEWARE,PFX(持久性框架),ROA’D,QCServicesLayer框架,AdvancedSoftwareArchitecturePlatform
4
商务和金融
Asyn,SanFrancisco,BOOF,PFC/OpenFrame,OmniBuilder,RuleParsing,FileParsing,CSFramelets
5
保险
Asyn,SanFrancisco
6
医疗
HBOC应用框架,MedicalBusinessObject框架,AdvancedSoftwareArchitecturePlatform,PhilipsNewYorkProject(开发中)
7
教育和娱乐
Multimedia框架
8
电信和网络
适应性面向对象事件过滤框架,AdvancedSoftwareArchitecturePlatform,CORTAN,ProtocolLayer框架,ACE,SIGAL,DORB,Jadve
9
工业和制造业
OMAC,PrismTechBOF和CORBA服务
10
软件开发
CLOSMetaObjectProtocol,G++,OPTF,LAMA
八、企业应用架构模式
做企业应用开发需要了解一些企业应用开发基础知识,比如分层架构、WEB表现、业务逻辑、数据库映射、并发、会话、分布策略等等。
通过使用场景、解决方案、UML等手段详细介绍了设计模式(包括一些常用的设计模式GOF23)。
下面这些模式是干什么的、它们解决什么问题、它们是如何解决问题的。
这样,如果你碰到类似的问题,就可以从中找到相应的模式。
可以为你节约成本、缩短项目周期时间、避免风险,以确保项目能够完美的完成。
1、三个基本层次:
表现层、领域层、数据源层
层次
职责
表现层
提供服务,显示信息(例如在Windows或HTML页面中,处理用户请求(鼠标点击、键盘敲击等),HTTP请求,命令行调用,批处理API)
领域层
逻辑,系统中真正的核心
数据源层
与数据库,消息系统、事务管理器及其他软件包通信
关于依赖性的普遍性原则:
领域层和数据源层绝对不要依赖于表现层。
一旦选择了处理节点,接下来就应该尽可能使所有代码保持在单一进程内完成(可能是在同一个节点上,也可能拷贝在集群中的多个节点上)。
除非不得已,否则不要把层次放在多个进程中完成。
因为那样做不但损失性能,而且增加复杂性,因为必须增加类似下面的模式,如远程外观和数据传输对象。
复杂性增压器:
分布、显式多线程、范型差异、多平台开发以及极限性能要求(如每秒100个事务以上)。
2、领域逻辑
领域逻辑的组织可以分成三种主要模式:
事务脚本、领域模型、表模块。
三者之间的区别:
事务脚本是一个过程来控制一系列动作逻辑的执行。
领域模型不再是由一个过程来控制用户某动作的逻辑,而是由每一个对象都承担一部分相关逻辑。
这些对象可以看成是领域的不同组成部分。
表模块只有一个公共的合同类实例,而领域模型对数据库中每一个合同都有一个相应的合同类的实例。
3、映射到关系数据库
在使用领域模型的时候,它的读取应该把相关联的对象也一块读出来。
例如,读取一个合同,应该把合同涉及到的产品和定购厂商的对象加载到内存中。
由时候为了避免这些没有必要的连带读取,我们可以使用【延迟加载】模型。
读取数据的时候,性能问题可能回变得比较突出。
这就导致了几条经验法则。
1)、尽可能一次查询多个记录,不要一次查询一个记录,然后进行多次查询。
可以一次查询多条相关的记录,例如使用联合查询。
或者使用多条SQL语句。
2)避免多次进入数据库的方法是使用连接(Join),这样就可以通过一次返回多个表。
可以制作一个入口,让入口完成相关数据的一次性读取。
3)数据库中进行优化。
DBA来优化数据库。
映射到关系数据库的时候,一般会遇到三种情况:
1) 自己选择数据库方案。
2) 不得不映射到一个现有数据库方案,这个方案不能改变。
3) 不得不映射到一个现有数据库方案,但这个方案是可以考虑改变的。
最简单的情况是自己选择数据库方案,并且不用迁就领域逻辑的复杂性。
当已经存在一个数据库方案的时候,应该逐步建立领域模型并包括数据映射器,把数据保存到现有的数据库中。
4、并发
并发问题:
更新丢失和不一致读。
并发问题,人们提出了各种不同的解决方案。
对于企业应用来说,有两个非常重要的解决方案:
一个是隔离,一个是不变性。
隔离是划分数据,使得每一片数据都可能被一个执行单元访问。
比如文件锁。
不变性是识别那些不变的数据,不用总考虑这些数据的并发问题而是广泛地共享
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 架构 学习 小结