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

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

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

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

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

rganization–One-manCompany机构组织的例子——家庭作坊6ExamplesfromOrganization–MiddletoSmallsizedCompany机构组织的例子——中小公司7ExamplesfromOrganiza

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

ComplicatedSystems软件开发——大型复杂系统的开发11SoftwareCrisis软件危机Softwaresystemsbecomeslargeraswellasmorecomplex,thereliabilityis

suebecomesmoreandmoreserious.Softwarecrisisbeginstoburst（爆发）.Projectsrunover-budgetandover-time.Projectswereunm

anageableandthecodesweredifficulttomaintain.Softwareoftendidnotmeetrequirements.12EmergeofSoftwareEngineering(SE)软件工

程的诞生Theterm"softwarecrisis"wascoinedbyF.L.BaueratthefirstNATOSoftwareEngineeringConferencein1968atGarmisch,Germany.1968年在德国召

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

程”？EngineeringmeansSolveproblematlowestcostGuidedbyscientificknowledgeEquippedwithmethodologyReliedonsuitabletoolsPurpose:Leto

rdinarypersonbeabletodowhatcanonlybeaccomplishedbyexpertinthepast14EvolutionofEngineering工程的进化15StagesofEngineering工程化的步伐手工(Craft)商业(Commerical

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

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

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

ies性能>功能SOA，MDA，SaaS(Softwareasaservice)...ERP（企业级应用）、E-Business/Digital-Government（电子商务/电子政务/电子交易）、GridComputing网格、CloudComputing云计算…

18OriginofSAConceptsStudiesonSAdatedbackto1960’s,withfocusonsoftwarestructure.1969年，Brooksproposedtheconceptof―architecture‖tosepara

tedesignfromimplementation.Theterm―architecture‖wasfirstusedtomeanadescriptionofacomputersystemthatappliedequallyt

omorethanoneactualsystem19OriginofSAConcepts1968年，EdsgerDijkstraproposedtheideaoflayersForexample,programswithinOScanbeclassifiedintodifferentlaye

rs,onlyprogramsinneighboringlayerscanaccesseachother.Organizedinthisway,systemdevelopmentandmaintenancecanbesimplifiedgreatly.20Orig

inofSAConcepts1970年代初，DavidParnasproposedaseriesofimportantideas1972年，信息隐蔽(information-hiding)1974年，软件结构(softwarestructures)

1975年，程序家族(programfamilies)Aprogramfamilyisasetofprogramswhosecommonpropertiesaresoextensivethatitisadvantageoustostudythosepropertiesbefor

einvestigating（调查）individualmembers.21OriginofSAConcepts1976年，FrankDeRemerandHansKronproposedMIL75（模块

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

intheLarge(PITL)structuringlargecollectionsofmodulestobuildsystemsdevelopingindividualmodulesMegaprogramming-Aconceptualsoftwaredev

elopmentframeworkthatunitesanumberofideascomponent-baseddevelopmentsoftwarereuseproduct-linesFormalMethod=SpecificationLanguage（规格语言）+FormalReas

oningTransformationalSystemsreduceprogramminglabor,improveprogramreliability,andupgrade（使上升）programperformance23F

ormationofSASA的形成Researchworkcarriedoutin1990’sDewaynePerryandAlexanderWolfDavidGarlanandMaryShawSAstylesDSSA1995GoFpublished―DesignPatterns‖1

994RationalRosereleasedumlsuits1995TheMythicalMan-Monthreprinted2425DefinitionsofSA―Thereisnostandard,universal

ly-accepteddefinitionoftheterm,forsoftwarearchitectureisafieldinitsinfancy（初期）,althoughitsrootsrundeepinsoftwareengineering.‖http://www.sei.cmu.e

du/architecture/definitions.html26DefinitionsofSALenBass,PaulClements,RickKazman定义Thesoftwarearchitectureofaprogramor

computingsystemisthestructureorstructuresofthesystem,whichcomprise（由..组成）softwareelements,theexternallyvisiblepropertiesoft

hoseelements,andtherelationshipsamongthem.27DefinitionsofSABooch,Rumbaugh,andJacobson,1999:Anarchitectureisthesetofsignificantdecisionsabouttheorg

anizationofasoftwaresystem,theselectionofthestructuralelementsandtheirinterfacesbywhichthesystemiscomposed,togetherwiththeirbehavi

orasspecifiedinthecollaborations（合作）amongthoseelements,thecompositionofthesestructuralandbehavioralelementsintoprogressively

largersubsystems,andthearchitecturalstylethatguidesthisorganization---theseelementsandtheirinterfaces,theircol

laborations,andtheircomposition(TheUMLModelingLanguageUserGuide,Addison-Wesley,1999).28DefinitionsofSAPerrya

ndWolf,1992:Asetofarchitectural(or,ifyouwill,design)elementsthathaveaparticularform.PerryandWolfdistinguishbetweenprocessingeleme

nts,dataelements,andconnectingelements,andthistaxonomy（分类学）byandlargepersiststhroughmostotherdefinitionsandapproaches.29DefinitionsofSAGarlanandSh

aw,1993:...beyondthealgorithmsanddatastructuresofthecomputation;designingandspecifyingtheoverallsystemstructureemergesasa

newkindofproblem.Structuralissuesincludegrossorganizationandglobalcontrolstructure;protocolsforcommunication,synchronization,an

ddataaccess;assignmentoffunctionalitytodesignelements;physicaldistribution;compositionofdesignelements;scalingandp

erformance;andselectionamongdesignalternatives."30DefinitionsofSAGarlanandShaw’sdefinitioncanbesimplifiedasArchitecture=Compone

nts+Connectors+Constrains体系结构=组件+连接件+约束31EvolutionofSA(SA的发展)1980’sUseinformalBox-and-linediagrams使用非正式的框图Rel

iesonexpert’speculiarexperiences依靠专家的特定经验Adoptsporadicallyarchitecturestyles不规范、多样地使用体系结构模式和风格1990’sRealizethevalueofSA认识到了体系结构的价值R

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

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

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

分析Asitevolves,thesystemisdifficulttocomplywithoriginalarchitecture随着系统的演化，难以保持同系统原有体系结构的一致Lackeffectivetools

toassist（帮助）indesign,analysisandvalidationonarchitecture难以开发有效的工具，辅助人们进行体系结构的设计、性质分析和验证33CurrentStatus

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

ojectsonSA:STARS,DODCARDS,DODPRISM,DODRAPIDE,StanfordUni.C2styleandADL,CaliforniaUni.ABLECMUACMEAr

chitectureInterchangeLanguage,CMUVitruvius,CMU34CurrentStatus(3)发展现状(3)ActiveresearchtopicsinSA当前软件体系结构研究和实践中，一

些最活跃的领域包括：Compilationofvariousarchitecturestyles各种体系结构风格的汇编和总结ArchitectureDescriptionLanguage体系结构描述语言FormalfoundationofSA体系结构的形式化基础Ana

lysistechniquesofSA体系结构分析技术SA-baseddevelopment基于体系结构的开发方法SAinverseengineering体系结构重建和再工程ToolsandenvironmentforSAdesign支持体系结构设计的工具和环境DSSA特定领域的软件

体系结构35FutureDirectionsFormalmethodsforarchitecturesInformationexchangeamongvariousADLsIntelligent（智能的）

designtoolsandenvironmentsSoftwarearchitectureengineeringEvolutionofarchitectures36EnvisioningSA预想软件架构SAisinfluencedbyavarietyofenvironment

alfactors商业、技术、组织等环境因素影响架构Inreturn,SAinfluencesenvironment反过来，架构影响环境37TheArchitectureBusinessCycle(ABC)AB

Ciscycleofinfluences,fromtheenvironmenttothearchitectureandbacktotheenvironment.Thebusiness/organizationalenvironmentnecessarilyaffec

tsarchitecturaldesigndecisions.Thesoftwarearchitectureinturnchangesthebusinessenvironment.Architecturaldesignispartofe

verystepofthedevelopmentprocess.Theseinfluencesstronglyaffecttheorganization’sbottomline.38TheEnvironme

ntInfluencesDesignsStakeholdersinasoftwaredevelopmenteffortEndusersCustomersDevelopersProjectmanagerMaintainersMarketingstaff…Ever

ystakeholderhasadifferentsetofconcerns,e.g.,runtimebehavior,hardwarecompatibility（兼容性）,andsoon.Thedifferentstakeholders’con

cernsmaycontradict（反驳）eachotherandmaychangeduringtheproject.3940AttributesImportanttoDifferentStakeholde

rsPerformanceandresourceutilizationCulturaladaptibilityReliabilityanddataintegrityModifiabilityandmaintainabi

lityUsabilityandinteroperabilityTestabilityPlatformcompatibilityAvailabilitySecurityBehavior…41BusinessEnvironmentan

dOrganizationalStructureImmediatebusiness（短期）influencesareexistingassetslikearchitecturesandproductsbasedonthemthatinfluencedesigndecisions.Lo

ng-termbusiness（长期的）influencesarestrategicgoalsfortheorganization,suchasinfrastructure（基础设施）development,thatinfluencedesigndecisio

ns.Organizationstructureinfluencesarchitecturewhennecessaryspecializedexpertiseexistsordoesnotexistwithintheorganizatio

n.42TheArchitect’sBackgroundandExperienceSuccessfulpreviousexperiencesmakearchitectswanttoreusethesuccessfulstrategyNegativeprevious

experiencesmakearchitectswanttoavoidusinganapproachagainPriorexposure（暴露）topreviousarchitecturalpatternsorothereducationcaninfluenceth

earchitectStandardindustrypracticesinthearchitect’sprofessionalcommunity,e.g.,Web-based,object-oriented,middleware-backedinformatio

nsystemdesigns,willplayastrongrole43Influencesonthearchitecture44TheArchitectureBusinessCycle45ArchitectureDesignChangetheBusi

nessEnvironmentTheyaffectthestructureoftheorganization.Theyaffectthebusinessgoalsoftheorganization.Theya

ffectcustomerrequirementsfornewproducts.Theyaffecthowfuturearchitecturesaredesigned.46ArchitectureDesignChangetheBusines

sEnvironmentSoftwarearchitecturesaffectthestructureofsoftwaredevelopmentorganizations.Anarchitectur

eprescribes（规定）thesoftwareunitstobedeveloped.Thesoftwareteamnormallyorganizesaccordingtothesoftwareunits.Teamstend

tospecializeandbecomeembedded（嵌入式的）intheorganizationalstructure.47ArchitectureDesignChangetheBusinessE

nvironmentSoftwarearchitectureseventuallyaffectthegoalsofasoftwaredevelopmentorganization.Aninitialentryintosomemarketisafo

otholdthatwillleadtonewopportunities.Anorganizationwillchooseopportunitiesthatbestcapitalize（使资本化）onexisting,provenarchitectures.48ArchitectureDesig

nChangetheBusinessEnvironmentSoftwarearchitecturesalsoaffectcustomerrequirementsfornewproducts.Anexistin

gproduct’sarchitecturecanserveasthefoundationforaproductline.Customersrecognizethepotentialforloweredcostsandfastertimetomarketthroughreuseofanexi

stingarchitecture.Customersmaybewillingtorelaxfunctionalrequirementsinordertoachievethesebenefits.49SAAffectstheDevelopmentProcess

Softwarearchitectureisanimportantcomponentofthelargeroverallsoftwaredevelopmentprocess.Creatingthebusinesscas

eUnderstandingrequirementsCreatingorselectingthearchitectureCommunicatingthearchitectureAnalyzingorevaluat

ingthearchitectureImplementingbasedonthearchitectureEnsuringconformancetothearchitecture50SAAffectstheDevelopmentPro

cessArchitecturalknowledgeisessentialforunderstandingtheconstraints（约束）andassumptions（假设）involvedinmakingabusinesscaseforap

roduct:CostCustomermarketTargetedtimetomarketInterfacestoothersystemsLimitations51SAAffectstheDevelopmentProcess

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

determiningacompletesetofrequirementswillneedatleastareferencearchitecture,soaniterativerequirementsengineeringprocessisalmostalwaysnecessary

52SAAffectstheDevelopmentProcessArchitecturalanalysistechniqueshelpsoftwareteamsevaluateanarchitectureAr

chitectstypicallyconsidermultiplecompetingdesigns.Inattribute-drivendesign,candidatearchitecturesareevaluatedaccordingtotheirabilitytosupportdes

iredqualityattributes.OnemethodforcomparingarchitecturesistheArchitectureTradeoffAnalysisMethod(ATAM)fromtheCMUSoft

wareEngineeringInstitute.53SAAffectstheDevelopmentProcessSoftwarearchitectsneedtoensurethattheimplementationremainsfaithfultothearchitecturald

esign.Thearchitecturaldesignneedstobecommunicatedeffectivelytothedevelopers.Architectsneedtomonitorthedevelopmentprocess.Ifpossib

le,thedevelopmentinfrastructureshouldenforceconformancetothearchitecturespecifications.Asthearchitecturematuresandevolves,itmus

tbekeptsynchronizedwiththedesigndocumentation.Inthecasethatproperdesigndocumentationdoesnotexist,softwarearchitecturereconstru

ctiontoolsmaybeuseful.54SAAffecttheBottomLineAnarchitect’sdesigndecisionshavelong-termfinancialconsequencesforasoftwaredevelopmentorgani

zation.Thearchitecturehasapivotalroleinthesoftwaredevelopmentprocess.Ithasabigimpactonasystem’sabilitytomeetqualitygoals.Itsupports(ordoesn’ts

upport)reuseatmultiplelevels.55SAAffecttheBottomLineThearchitectureiscommonabstractionthatallstakeholderscan

useformutualunderstanding.We’vealreadyseen,architecturaldesigndecisionshaverepercussionsthroughoutthedevelopmentcycle.Changingthearchitec

tureduringthedesignphaseiseasy;it’smuchharderlater.Thearchitectureseverelyconstrainsthedetailedsoftwaredesign.Thearchitectureprofoundlyaffectsthep

lanning,schedule,andbudgetfortheentireproject.56SAAffecttheBottomLineHavingtherightarchitectureiscrucialformeetingqualitygoals.Performancemig

htdependonthevolumeofinter-elementcommunication.Modifiabilityrequiresseparationofconcernsinthearchitectur

e.Securityrequiresarchitecturalelementsforaccesscontrol.Scalabilityrequiresarchitecturalbreakdownwherecertainelementscanbereplicated

orreplacedwithhigher-performanceversions.Reusabilityrequirescomponentswithouttoomanyattachmentstothesurroundingenvironment57WhyIsArchi

tectureSoImportant?CommunicationamongstakeholdersCapturesearlydesigndecisionsTransferableabstractionofth

esystem58Architecture&DesignDecisionsDefinesconstraintsonimplementationRelatedtoorganizationalstructureEnablesQ

ualityattributes(e.g.,performance,safety,security)AllowssystemspropertiestobepredictedHelpsevolutionaryprototypingHelpsreasonab

outchangeCostandschedulingestimates59ATransferable,ReusableModelSoftwareproductlinesshareacommonarchit

ectureBuildusinglarge,externallydevelopedpiecesRestrictvocabularyofdesignchoicestominimizedesigncomplexityPerm

itstemplate-baseddevelopment60ResponsibilitiesofArchitectsGuidethetechnicaldirectionsManageconflictinginf

luencesMinimizeunforeseendifficulties61GuidethetechnicaldirectionsConvertcustomerrequirementsintoatechnicaldesignEnsurethatthetechnicaldesignm

eetsqualityrequirementsCommunicatewithstakeholdersthroughdetailedtechnicalpresentationsListentostakeh

oldersandbuildconsensusReviewdevelopercodeandensureconformancetothearchitectureandgoodcodingpracticesServeasamentorfordevelopers62ManageC

onflictingInfluencesThearchitectmustidentifythestakeholders.Thearchitectmustengagethestakeholderstosolicittheirneedsandexpec

tations.Thearchitectshouldusearchitecturereviewsanditerativeprototypingasmeanstosolicittheseneedsandexpectations.6364TypicalDes

ignTrade-offsFunctionalityvs.UsabilityPerformancevs.ModifiabilityCostvs.RobustnessEfficiencyvs.Port

abilityRapiddevelopmentvs.FunctionalityCostvs.ReusabilityBackwardCompatibilityvs.Readability65MinimizeUnforeseenDifficul

tiesCasestudiesofsuccessfularchitecturesgivecluesaboutthebestapproachtoanewproblemandarerichsourcesofdesignpatterns.Architecturalassessm

ent(beforethesystemisbuilt)helpsdeterminewhichcompetingdesignalternativesarebetter.Incrementalarchitecture-bas

eddevelopmenthelpstouncoverdesignflawsbeforetheykillaproject.66AsuccessfulsoftwarearchitectshouldBeanexcellentprog

rammerwithsignificantdesignandimplementationexperience.Stayup-to-datewithnewtoolsandtechnologies,andknowrelevantdesignp

atternsandanti-patterns.Beagoodpolitician,negotiator,andcommunicatorwhocanspeakthelanguagesofthebusinessteamandthetechnicalteam.－Youtypicallyneedse

veralyearsofprofessionalexperiencetobealeadsoftwarearchitectinamaturesoftwaredevelopmentorganization.67ChiefArchitectBillGatesa

ctedasthechiefarchitectofMicrosoft.丁磊68BestPracticesinSADesignThearchitectureshouldbetheproductofonearchitect(orafewarc

hitectswithadefinedleader).Thearchitectshouldbegivenfunctionalrequirementsandaprioritizedlistofnon-funct

ionalrequirementsorqualityattributes(security,modifiability,andsoon)thatneedtobesatisfied.Thearchitectureshouldbedocumentedfrommultip

leperspectiveswellenoughtofacilitatecommunicationandunderstandingbetweenallstakeholders.Thearchitectureshouldbecircul

atedtothesystem’sstakeholdersandtheyshouldparticipateactivelyinanarchitecturereview.69BestPracticesinSADesignThearchitectureshouldbeanalyzedf

orquantitativemeasureslikemaximumthroughputandformallyevaluatedforqualityattributesbeforeitistoolatetochangethea

rchitecture.Itshouldbepossibletoimplementa―skeletal‖versionofthearchitecturewherecommunicationisexercisedbutfunctiona

lityisminimal.Thisallowsforincrementalgrowth.Resourcecontentionareasshouldbeidentifiedandresolved,andthesolutionshouldbesp

ecified,circulated,andmaintained.70RecommendationsforStructuringSoftwareThearchitectureshouldbecomposedofwell-definedmodulesthatutilizetheprinciples

ofinformationhiding(encapsulation)andseparationofconcerns.Themodulesshouldhideanyidiosyncrasiesoftheexistingcomputinginfrastructure.Eachmo

duleshouldhaveawell-definedinterfaceencapsulatingorhidingimplementationstrategiesanddatastructures.

Qualityattributesshouldbeachievedusingwell-knownarchitecturalpatternswiththeirassociatedtactics.71RecommendationsforStruc

turingSoftwareThearchitectureshouldnotdependonfunctionalityofaspecificversionofacommercialproductortool.Ifcomme

rcialtoolsareunavoidable,thearchitecturemustbestructuredsothatchangingthetoolhasminimalimpactontherestofthesystem.

Modulesproducingdatashouldbeseparatefrommodulesthatconsumedata.Thisimprovesmodifiabilitywhenchangesareconfi

nedtotheproducerorconsumer.Forparallelarchitectures,thethreadsshouldbecarefullyspecifiedseparatelyfromthemodules,sinceaprocessmightexecuteinmor

ethanonemodule.72RecommendationsforStructuringSoftwareThreadsshouldbewrittensotheycaneasilymigratefromoneprocessortoanother.Thecompleteset

ofinteractionpatternsshouldbesmall,simple,andwell-defined.Theresultingconceptualintegrityinthearchitecturewi

llleadtosmoothdevelopment..