【文档说明】1-软件体系结构概念.课件.ppt，共(72)页，2.064 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50406.html

以下为本文档部分文字说明：

1SoftwareArchitecture软件体系结构起源、定义、意义和研究现状张平健华南理工大学软件学院2Examplesfromarchitecture–Kennel建筑的例子——狗舍一个人搭建，需要•最小化建模•简单的过程•简

单的工具3Examplesfromarchitecture–House建筑的例子——住房一个团队高效和适时地建造，需要•仔细的建模•良好定义的过程•良好的工具4Examplesfromarchitecture–Skyscraper建筑的例

子——摩天大楼5ExamplesfromOrganization–One-manCompany机构组织的例子——家庭作坊6ExamplesfromOrganization–MiddletoSmallsizedCompany机构组织的例子——中小公司7Examp

lesfromOrganization–InternationalGroup机构组织的例子——跨国集团8SoftwareDevelopment–Single-handed软件开发——单枪匹马9Softwa

reDevelopment–TeamWork软件开发——团队开发10SoftwareDevelopment–LargeComplicatedSystems软件开发——大型复杂系统的开发11SoftwareCrisis软件危机Softwaresystemsbecomeslargeraswellas

morecomplex,thereliabilityissuebecomesmoreandmoreserious.Softwarecrisisbeginstoburst（爆发）.Projectsrunover-budgeta

ndover-time.Projectswereunmanageableandthecodesweredifficulttomaintain.Softwareoftendidnotmeetrequirements.12EmergeofSoftwareEngineering(SE

)软件工程的诞生Theterm"softwarecrisis"wascoinedbyF.L.BaueratthefirstNATOSoftwareEngineeringConferencein1968atGarmisch,Germany.1968年在德国召开的NATO（Nor

thAtlanticTreatyOrganization,北大西洋公约组织）会议上首次提出了“软件工程”概念，希望用工程化的原则和方法来克服软件危机13What’sEngineering?什么是“工程”？EngineeringmeansSolvepro

blematlowestcostGuidedbyscientificknowledgeEquippedwithmethodologyReliedonsuitabletoolsPurpose:Letordinarypersonbeabletodowhatcanonlyb

eaccomplishedbyexpertinthepast14EvolutionofEngineering工程的进化15StagesofEngineering工程化的步伐手工(Craft)商业(Comm

erical)工程(ProfessionalEngineering)行家里手和业余天才熟练的工匠受过系统教育的专业人员直觉与强力既定程序分析与理论偶然的进步注重实效地优化以科学为指导地升级换代不经意的推广言传身教专业教育课程奢侈地使用原料注

重成本与原料利用原料多次利用生产是为了使用而不是出售为销售而生产市场份额16SE的发展17UnderstandingofSA软件架构认识与实践Program=Datastructure+Algorithm程序=数据结构+算法P

rogram=Object+Object程序=对象+对象System=Component+Component系统=构件+构件System=Element+Connector系统=组件+连接件Overallstructure>Technicaldetails整体结构>技术细节

Qualities>Functionalities性能>功能SOA，MDA，SaaS(Softwareasaservice)...ERP（企业级应用）、E-Business/Digital-Government（电子商务/电子政务/电子交易）、GridCom

puting网格、CloudComputing云计算…18OriginofSAConceptsStudiesonSAdatedbackto1960’s,withfocusonsoftwarestructure.1969年，Brooksproposedtheconceptof―arch

itecture‖toseparatedesignfromimplementation.Theterm―architecture‖wasfirstusedtomeanadescriptionofacomputersystemthatappliedeq

uallytomorethanoneactualsystem19OriginofSAConcepts1968年，EdsgerDijkstraproposedtheideaoflayersForexample,programswithinOScanbeclassifiedintodifferen

tlayers,onlyprogramsinneighboringlayerscanaccesseachother.Organizedinthisway,systemdevelopmentandmaintenancecanbesimplifiedgreatly.20Ori

ginofSAConcepts1970年代初，DavidParnasproposedaseriesofimportantideas1972年，信息隐蔽(information-hiding)1974年，软件结构(softwarestructures)1975年，程序家族(

programfamilies)Aprogramfamilyisasetofprogramswhosecommonpropertiesaresoextensivethatitisadvantageoustost

udythosepropertiesbeforeinvestigating（调查）individualmembers.21OriginofSAConcepts1976年，FrankDeRemerandHansKronpro

posedMIL75（模块连接语言）“Programming-in-largeversusprogramming-in-small‖,[IEEETrans.onSE,June1976]22OriginofSAConceptsProgrammingintheLarge

(PITL)structuringlargecollectionsofmodulestobuildsystemsdevelopingindividualmodulesMegaprogramming-Aconceptualsoftwaredevel

opmentframeworkthatunitesanumberofideascomponent-baseddevelopmentsoftwarereuseproduct-linesFormalMethod=SpecificationLanguage（

规格语言）+FormalReasoningTransformationalSystemsreduceprogramminglabor,improveprogramreliability,andupgrade（使上升）programperformance23

FormationofSASA的形成Researchworkcarriedoutin1990’sDewaynePerryandAlexanderWolfDavidGarlanandMaryShawSAstylesDSSA1995GoFpublished―Des

ignPatterns‖1994RationalRosereleasedumlsuits1995TheMythicalMan-Monthreprinted2425DefinitionsofSA―T

hereisnostandard,universally-accepteddefinitionoftheterm,forsoftwarearchitectureisafieldinitsinfancy（初期）,althoughitsrootsrundeepins

oftwareengineering.‖http://www.sei.cmu.edu/architecture/definitions.html26DefinitionsofSALenBass,PaulClements,RickKazman

定义Thesoftwarearchitectureofaprogramorcomputingsystemisthestructureorstructuresofthesystem,whichcomprise（由..组成）softwareelements,theexternallyvisib

lepropertiesofthoseelements,andtherelationshipsamongthem.27DefinitionsofSABooch,Rumbaugh,andJacobson,1999:Anarchitectureisthesetofsigni

ficantdecisionsabouttheorganizationofasoftwaresystem,theselectionofthestructuralelementsandtheirinterf

acesbywhichthesystemiscomposed,togetherwiththeirbehaviorasspecifiedinthecollaborations（合作）amongthoseelements,thecompositionofthesestruct

uralandbehavioralelementsintoprogressivelylargersubsystems,andthearchitecturalstylethatguidesthisorganization---theseelementsandt

heirinterfaces,theircollaborations,andtheircomposition(TheUMLModelingLanguageUserGuide,Addison-Wesley,1999).28DefinitionsofSAPerryandWolf,1992:Aset

ofarchitectural(or,ifyouwill,design)elementsthathaveaparticularform.PerryandWolfdistinguishbetweenprocessingelements,

dataelements,andconnectingelements,andthistaxonomy（分类学）byandlargepersiststhroughmostotherdefinitionsandapproaches.29Definit

ionsofSAGarlanandShaw,1993:...beyondthealgorithmsanddatastructuresofthecomputation;designingandspecifyingtheoverallsystemstructuree

mergesasanewkindofproblem.Structuralissuesincludegrossorganizationandglobalcontrolstructure;protocolsforcommunication,synchronization,anddataaccess;a

ssignmentoffunctionalitytodesignelements;physicaldistribution;compositionofdesignelements;scalingandperformance;andselectionamongdesignalternatives."

30DefinitionsofSAGarlanandShaw’sdefinitioncanbesimplifiedasArchitecture=Components+Connectors+Constrains体系结构=组件+连接件+约束31EvolutionofSA(SA的发展)198

0’sUseinformalBox-and-linediagrams使用非正式的框图Reliesonexpert’speculiarexperiences依靠专家的特定经验Adoptsporadical

lyarchitecturestyles不规范、多样地使用体系结构模式和风格1990’sRealizethevalueofSA认识到了体系结构的价值Requiredocumentingandreviewingarchitecture开发过程

中要求体系结构文档，并开始体系结构评审ProductsforSAdesignandintegrationemerge产品化、商业化的体系结构标准和组件集成框架开始出现Standardizevocabular

y,symbolsandtoolsinSAdesign规范化体系结构设计中的词汇、符号和工具PublishbooksonSA软件体系结构的书籍和课程32CurrentStatus(1)发展现状1SAdesi

gnisnotunderstoodthoroughlybydevelopers体系结构设计只是被开发人员含糊地理解ItisdifficulttocarryoutconsistencyandintegrityanalysisofSAdesign难以对体系结构设计作出一致性或完整性的分析

Asitevolves,thesystemisdifficulttocomplywithoriginalarchitecture随着系统的演化，难以保持同系统原有体系结构的一致Lackeffectivetoolstoassist（帮助）indesign,an

alysisandvalidationonarchitecture难以开发有效的工具，辅助人们进行体系结构的设计、性质分析和验证33CurrentStatus(2)发展现状(2)DoDemphasizesSA-centeredsoftwa

rereuse在“软件复用的展望和策略”[DoD1992]报告中，美国国防部强调了“以体系结构为中心的复用”在整个软件生存周期中，对于软件开发和支持的重要性。ListofresearchprojectsonSA:

STARS,DODCARDS,DODPRISM,DODRAPIDE,StanfordUni.C2styleandADL,CaliforniaUni.ABLECMUACMEArchitectureInterchangeLang

uage,CMUVitruvius,CMU34CurrentStatus(3)发展现状(3)ActiveresearchtopicsinSA当前软件体系结构研究和实践中，一些最活跃的领域包括：Compilationofva

riousarchitecturestyles各种体系结构风格的汇编和总结ArchitectureDescriptionLanguage体系结构描述语言FormalfoundationofSA体系结构的形式化基础AnalysistechniquesofSA体系结构分析技术SA

-baseddevelopment基于体系结构的开发方法SAinverseengineering体系结构重建和再工程ToolsandenvironmentforSAdesign支持体系结构设计的工具和环境DSSA特定领域的软件体系结构35FutureDirectionsFo

rmalmethodsforarchitecturesInformationexchangeamongvariousADLsIntelligent（智能的）designtoolsandenvironmentsSoftwarearchitectureengineeringEvoluti

onofarchitectures36EnvisioningSA预想软件架构SAisinfluencedbyavarietyofenvironmentalfactors商业、技术、组织等环境因素影响架构Inreturn,SAinfluencesenvironment反过来，架构影响环境37

TheArchitectureBusinessCycle(ABC)ABCiscycleofinfluences,fromtheenvironmenttothearchitectureandbacktothe

environment.Thebusiness/organizationalenvironmentnecessarilyaffectsarchitecturaldesigndecisions.Thesoftwarearchitecture

inturnchangesthebusinessenvironment.Architecturaldesignispartofeverystepofthedevelopmentprocess.Theseinfluencesstr

onglyaffecttheorganization’sbottomline.38TheEnvironmentInfluencesDesignsStakeholdersinasoftwaredevelopmenteffortEndusersCustom

ersDevelopersProjectmanagerMaintainersMarketingstaff…Everystakeholderhasadifferentsetofconcerns,e.g.,runtime

behavior,hardwarecompatibility（兼容性）,andsoon.Thedifferentstakeholders’concernsmaycontradict（反驳）eachothe

randmaychangeduringtheproject.3940AttributesImportanttoDifferentStakeholdersPerformanceandresourceutilizationCultur

aladaptibilityReliabilityanddataintegrityModifiabilityandmaintainabilityUsabilityandinteroperabilityTes

tabilityPlatformcompatibilityAvailabilitySecurityBehavior…41BusinessEnvironmentandOrganizationalStructureImmediatebusiness

（短期）influencesareexistingassetslikearchitecturesandproductsbasedonthemthatinfluencedesigndecisions.Long-te

rmbusiness（长期的）influencesarestrategicgoalsfortheorganization,suchasinfrastructure（基础设施）development,thatinfluencedesigndec

isions.Organizationstructureinfluencesarchitecturewhennecessaryspecializedexpertiseexistsordoesnotexistwithintheorganization.42TheArchitect’sBack

groundandExperienceSuccessfulpreviousexperiencesmakearchitectswanttoreusethesuccessfulstrategyNegativepreviousexperiencesma

kearchitectswanttoavoidusinganapproachagainPriorexposure（暴露）topreviousarchitecturalpatternsorothereducationcaninfluencethearchitectS

tandardindustrypracticesinthearchitect’sprofessionalcommunity,e.g.,Web-based,object-oriented,middleware-backedin

formationsystemdesigns,willplayastrongrole43Influencesonthearchitecture44TheArchitectureBusinessCycle45ArchitectureDesignChanget

heBusinessEnvironmentTheyaffectthestructureoftheorganization.Theyaffectthebusinessgoalsoftheorganization.Theyaffectcust

omerrequirementsfornewproducts.Theyaffecthowfuturearchitecturesaredesigned.46ArchitectureDesignChangetheBusinessEnvironm

entSoftwarearchitecturesaffectthestructureofsoftwaredevelopmentorganizations.Anarchitectureprescribes（规定）thesoftwareunitstobedeveloped.Thes

oftwareteamnormallyorganizesaccordingtothesoftwareunits.Teamstendtospecializeandbecomeembedded（嵌入式的）intheorganizationalst

ructure.47ArchitectureDesignChangetheBusinessEnvironmentSoftwarearchitectureseventuallyaffectthegoalsofasoftwaredevelopmentorganization.Aninitialent

ryintosomemarketisafootholdthatwillleadtonewopportunities.Anorganizationwillchooseopportunitiesthatbestcapitalize（使资本化）onexisting,proven

architectures.48ArchitectureDesignChangetheBusinessEnvironmentSoftwarearchitecturesalsoaffectcustomerrequirementsfornewproducts.An

existingproduct’sarchitecturecanserveasthefoundationforaproductline.Customersrecognizethepotentialforlow

eredcostsandfastertimetomarketthroughreuseofanexistingarchitecture.Customersmaybewillingtorelaxfunctionalrequirement

sinordertoachievethesebenefits.49SAAffectstheDevelopmentProcessSoftwarearchitectureisanimportantcomponentofthelargeroverallsoftwaredevelopmen

tprocess.CreatingthebusinesscaseUnderstandingrequirementsCreatingorselectingthearchitectureCommunicatingthearchitectureAnalyzingoreva

luatingthearchitectureImplementingbasedonthearchitectureEnsuringconformancetothearchitecture50SAAffectstheDevelopmentProcessArchitectu

ralknowledgeisessentialforunderstandingtheconstraints（约束）andassumptions（假设）involvedinmakingabusinesscaseforaproduct:Co

stCustomermarketTargetedtimetomarketInterfacestoothersystemsLimitations51SAAffectstheDevelopmentProcessRequiremen

tsengineeringUsecases/ScenariosRapidprototyping（样机研究）FinitestatemachinemodelsFormalspecificationsNormally,determiningacomplete

setofrequirementswillneedatleastareferencearchitecture,soaniterativerequirementsengineeringprocessisalmostalways

necessary52SAAffectstheDevelopmentProcessArchitecturalanalysistechniqueshelpsoftwareteamsevaluateanarchitectureArchitec

tstypicallyconsidermultiplecompetingdesigns.Inattribute-drivendesign,candidatearchitecturesareevaluatedaccordingto

theirabilitytosupportdesiredqualityattributes.OnemethodforcomparingarchitecturesistheArchitectureTrade

offAnalysisMethod(ATAM)fromtheCMUSoftwareEngineeringInstitute.53SAAffectstheDevelopmentProcessSoftwarearchitectsneedtoensurethattheimplementatio

nremainsfaithfultothearchitecturaldesign.Thearchitecturaldesignneedstobecommunicatedeffectivelytothedevelopers.Architectsneedtomonit

orthedevelopmentprocess.Ifpossible,thedevelopmentinfrastructureshouldenforceconformancetothearchitecturespecifications.Asthearchitecturematuresand

evolves,itmustbekeptsynchronizedwiththedesigndocumentation.Inthecasethatproperdesigndocumentationdoesnotexist

,softwarearchitecturereconstructiontoolsmaybeuseful.54SAAffecttheBottomLineAnarchitect’sdesigndecisionshavelong-termfinancialconse

quencesforasoftwaredevelopmentorganization.Thearchitecturehasapivotalroleinthesoftwaredevelopmentprocess.Ithasabigimpactonasy

stem’sabilitytomeetqualitygoals.Itsupports(ordoesn’tsupport)reuseatmultiplelevels.55SAAffecttheBottomLineThearchitectur

eiscommonabstractionthatallstakeholderscanuseformutualunderstanding.We’vealreadyseen,architecturaldesigndecisionshaverepercussionsthroughoutthedev

elopmentcycle.Changingthearchitectureduringthedesignphaseiseasy;it’smuchharderlater.Thearchitectureseverelyconstrainsthedeta

iledsoftwaredesign.Thearchitectureprofoundlyaffectstheplanning,schedule,andbudgetfortheentireproject.56SAAffecttheBottomLineHavingtheright

architectureiscrucialformeetingqualitygoals.Performancemightdependonthevolumeofinter-elementcommunication.Modifiabilityrequiresseparationo

fconcernsinthearchitecture.Securityrequiresarchitecturalelementsforaccesscontrol.Scalabilityrequiresarchite

cturalbreakdownwherecertainelementscanbereplicatedorreplacedwithhigher-performanceversions.Reusabilityrequirescomponentswithouttoomanyattachment

stothesurroundingenvironment57WhyIsArchitectureSoImportant?CommunicationamongstakeholdersCapturesearlydesigndecisionsTransferableabstra

ctionofthesystem58Architecture&DesignDecisionsDefinesconstraintsonimplementationRelatedtoorganizationalstructureEnablesQualityattributes(e.

g.,performance,safety,security)AllowssystemspropertiestobepredictedHelpsevolutionaryprototypingHelpsreasonaboutchangeCostandsche

dulingestimates59ATransferable,ReusableModelSoftwareproductlinesshareacommonarchitectureBuildusinglarge,externallydevelopedpiecesRestrictvocabula

ryofdesignchoicestominimizedesigncomplexityPermitstemplate-baseddevelopment60ResponsibilitiesofArchitectsGuidethetechnicaldirectionsManageconfli

ctinginfluencesMinimizeunforeseendifficulties61GuidethetechnicaldirectionsConvertcustomerrequirementsintoatechni

caldesignEnsurethatthetechnicaldesignmeetsqualityrequirementsCommunicatewithstakeholdersthroughdetailedtechnicalpresentationsListentostakeho

ldersandbuildconsensusReviewdevelopercodeandensureconformancetothearchitectureandgoodcodingpracticesServeasamentorfordevelopers62Ma

nageConflictingInfluencesThearchitectmustidentifythestakeholders.Thearchitectmustengagethestakeholderstosolicittheirnee

dsandexpectations.Thearchitectshouldusearchitecturereviewsanditerativeprototypingasmeanstosolicitthesen

eedsandexpectations.6364TypicalDesignTrade-offsFunctionalityvs.UsabilityPerformancevs.ModifiabilityCostvs.Robustne

ssEfficiencyvs.PortabilityRapiddevelopmentvs.FunctionalityCostvs.ReusabilityBackwardCompatibilityvs.Readability65MinimizeUn

foreseenDifficultiesCasestudiesofsuccessfularchitecturesgivecluesaboutthebestapproachtoanewproblemandarerichsourcesofdesignpatterns.Architecturalas

sessment(beforethesystemisbuilt)helpsdeterminewhichcompetingdesignalternativesarebetter.Incrementalarchitecture-baseddevelopmenthelpstouncoverd

esignflawsbeforetheykillaproject.66AsuccessfulsoftwarearchitectshouldBeanexcellentprogrammerwithsignificantdesignandimplementationexper

ience.Stayup-to-datewithnewtoolsandtechnologies,andknowrelevantdesignpatternsandanti-patterns.Beagoodpolitician,negotiator

,andcommunicatorwhocanspeakthelanguagesofthebusinessteamandthetechnicalteam.－Youtypicallyneedseveralyearsofprofessionalexperiencetobealeads

oftwarearchitectinamaturesoftwaredevelopmentorganization.67ChiefArchitectBillGatesactedasthechiefarchitectofMicrosoft.丁磊68BestPracticesinSADesign

Thearchitectureshouldbetheproductofonearchitect(orafewarchitectswithadefinedleader).Thearchitectshouldbegivenfunctionalrequ

irementsandaprioritizedlistofnon-functionalrequirementsorqualityattributes(security,modifiability,andsoon)

thatneedtobesatisfied.Thearchitectureshouldbedocumentedfrommultipleperspectiveswellenoughtofacilitatecommu

nicationandunderstandingbetweenallstakeholders.Thearchitectureshouldbecirculatedtothesystem’sstakeholdersandt

heyshouldparticipateactivelyinanarchitecturereview.69BestPracticesinSADesignThearchitectureshouldbeanaly

zedforquantitativemeasureslikemaximumthroughputandformallyevaluatedforqualityattributesbeforeitistoolatet

ochangethearchitecture.Itshouldbepossibletoimplementa―skeletal‖versionofthearchitecturewherecommunicationis

exercisedbutfunctionalityisminimal.Thisallowsforincrementalgrowth.Resourcecontentionareasshouldbeidentifi

edandresolved,andthesolutionshouldbespecified,circulated,andmaintained.70RecommendationsforStructuringSoftwareThearchitectu

reshouldbecomposedofwell-definedmodulesthatutilizetheprinciplesofinformationhiding(encapsulation)andseparationofconcerns.Themodulessh

ouldhideanyidiosyncrasiesoftheexistingcomputinginfrastructure.Eachmoduleshouldhaveawell-definedinterfacee

ncapsulatingorhidingimplementationstrategiesanddatastructures.Qualityattributesshouldbeachievedusing

well-knownarchitecturalpatternswiththeirassociatedtactics.71RecommendationsforStructuringSoftwareThearchitectureshouldnotdependonfunction

alityofaspecificversionofacommercialproductortool.Ifcommercialtoolsareunavoidable,thearchitecturemustbestructur

edsothatchangingthetoolhasminimalimpactontherestofthesystem.Modulesproducingdatashouldbeseparatefrommodulesthatconsu

medata.Thisimprovesmodifiabilitywhenchangesareconfinedtotheproducerorconsumer.Forparallelarchitectures,thethreadsshouldbe

carefullyspecifiedseparatelyfromthemodules,sinceaprocessmightexecuteinmorethanonemodule.72RecommendationsforStructuringSoftwareThreadsshouldbe

writtensotheycaneasilymigratefromoneprocessortoanother.Thecompletesetofinteractionpatternsshouldbesmall,simple,andwell-defined.T

heresultingconceptualintegrityinthearchitecturewillleadtosmoothdevelopment..