Software Architectureand the UMLGrady Booch2 Architecting a dog house Can be built by one personRequiresMinimal modelingSimple processSimple tools3 Architecting a houseBuilt most efficiently and timely by a teamRequiresModelingWelldefined processPower tools4 Architecting a high rise5 Early architectureProgress - Limited knowledge of theory6 Modern architectureProgress - Advances in materials - Advances in analysisScale - 5 times the span of the Pantheon - 3 times the height of Cheops7 Modeling a house8 Movements in civil architectureBronze age/Egyptian (Imhotep)Grecian/Roman (Vitruvius)Byzantine/RomanesqueGothicMannerism (Michelangelo, Palladio)BaroqueEngineering/Rational/National/RomanticArt noveauModern movement (Wright, LeCorbusier)Progress - Imitation of previous efforts - Learning from failure - Integration of other forces - Experimentation9 Kinds of civil architectureCommunityhouses, flats and apartments, gardens, education, hospitals, religionCommerceshops and stores, restaurants, hotels, office buildings, banks, airportsIndustryindustrial buildings, laboratories, farm buildingsLeisuresport, theaters and cinemas, museumsNeufert Architects DataThe Handbook of Building Types10 Forces in civil architectureAvoiding failure - Safety factors - Redundancy - EquilibriumCompressionLoadTensionLoadKinds of loads - Dead loads - Live loads - Dynamic loadsAny time you depart from established practice, make ten times theeffort, ten times the investigation. Especially on a very large project. - LeMessuier11 Shearing layers of change SiteSkinStructureServicesSpace planStuffBrand, How Buildings Learn12 Dimensions of software complexityHigher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performanceLower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performanceHighermanagement complexity - Large scale - Contractual - Many stake holders - “Projects”Lowermanagement complexity - Small scale - Informal - Single stakeholder - “Products”Defense MIS SystemDefense Weapon SystemTelecom SwitchCASE ToolNational Air TrafficControl SystemEnterprise IS(Family of ISApplications)CommercialCompilerBusinessSpreadsheetIS ApplicationDistributed Objects (Order Entry)Small ScientificSimulationLarge-ScaleOrganization/EntitySimulation An average software project: - 5-10 people - 10-15 month duration - 3-5 external interfaces - Some unknowns & risksEmbeddedAutomotive SoftwareIS ApplicationGUI/RDB (Order Entry)Walker Royce13 Forces in SoftwareTechnology churnOur enemy is complexity, and its our goal to kill it.Jan BaanPerformanceThroughputCapacityAvailabilityFail safeFault toleranceFunctionalityCostCompatibilityResilienceThe challenge over the next 20 years will not be speed or cost or performance;it will be a question of complexity.Bill Raduchel, Chief Strategy Officer, Sun Microsystems14 The domain of architectingThe “what”The “why”The “how”The “who”SatisfiesConstrainDefines roleProducesFollowsDefinesWojtek Kozaczynski15 We all know that .Architecture and design are the same thingArchitecture and infrastructure are the same thing is the architectureA good architecture is the work of a single architectArchitecture is flat, one blueprint is enoughArchitecture is just structureSystem architecture precedes software architectureArchitecture cannot be measured and validatedArchitecture is a ScienceArchitecture is an ArtPhilippe Kruchten16 Architecture defined (again)Architecture n (1555) 1: the art of science of building, specifically, the art or practice of designing and building structures and esp. habitable ones 2 a: formation or construction as or as if as the result of conscious act b: a unifying or coherent form or structure Merriam Websters Collegiate Dictionary10th edition17 Architecture defined (yet again)Software architecture encompasses the set of significant decisions about the organization of a software systemselection of the structural elements and their interfaces by which a system is composedbehavior as specified in collaborations among those elementscomposition of these structural and behavioral elements into larger subsystemarchitectural style that guides this organizationMary Shaw, CMUGrady Booch,Philippe Kruchten,Rich ReitmanKurt Bittner, Rational18 Architecture defined (continued)Software architecture also involvesusagefunctionalityperformanceresiliencereusecomprehensibilityeconomic and technology constraints and tradeoffsaesthetic concernsMary Shaw, CMUGrady Booch,Philippe Kruchten,Rich ReitmanKurt Bittner, Rational19 Architectural styleAn architecture style defines a family of systems in terms of a pattern of structural organization.An architectural style definesa vocabulary of components and connector typesa set of constraints on how they can be combinedone or more semantic models that specify how a systems overall properties can be determined from the properties of its partsMary Shaw, CMU20 Architecture metamodel21 ModelsModels are the language of designer, in many disciplinesModels are representations of the system tobebuilt or asbuiltModels are vehicle for communications with various stakeholdersVisual models, blueprintsScaleModels allow reasoning about some characteristic of the real system22 Many stakeholders, many viewsArchitecture is many things to many different interested partiesendusercustomerproject managersystem engineerdeveloperarchitectmaintainerother developersMultidimensional realityMultiple stakeholdersmultiple views, multiple blueprints23 Architectural viewAn architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective24 Architecturally significant elementsNot all design is architectureMain “business” classesImportant mechanismsProcessors and processesLayers and subsystemsArchitectural views = slices through models25 Characteristics of a Good ArchitectureResilientSimpleApproachableClear separation of concernsBalanced distribution of responsibilitiesBalances economic and technology constraints26 Representing System ArchitectureLogical ViewEnduser FunctionalityImplementation ViewProgrammers Software management Process ViewPerformanceScalabilityThroughput System integratorsDeployment ViewSystem topology Delivery, installationCommunicationSystem engineeringConceptualPhysicalUse Case View27 Relation Between Views Logical viewComponent viewProcess viewDeployment view28 How many views?Simplified models to fit the contextNot all systems require all views:Single processor: drop deployment viewSingle process: drop process viewVery Small program: drop implementation viewAdding views:Data view, security view29 The Value of the UMLIs an open standardSupports the entire software development lifecycleSupports diverse applications areasIs based on experience and needs of the user communitySupported by many tools30 Creating the UMLBooch methodOMTUnified Method 0.8OOPSLA 95OOSEOther methodsUML 0.9Web - June 96 publicfeedbackFinal submission to OMG, Sep 97First submission to OMG, Jan 97UML 1.1OMG Acceptance, Nov 1997UML 1.3UML 1.0UML partners31 UML PartnersRational Software CorporationHewlettPackardILogixIBMICON ComputingIntellicorpMCI SystemhouseMicrosoftObjecTimeOraclePlatinum TechnologyTaskonTexas Instruments/Sterling SoftwareUnisys32 MeyerBefore and after conditionsHarelStatechartsGamma, et alFrameworks and patterns,HP FusionOperation descriptions and message numberingEmbleySingleton classes andhigh-level viewWirfsBrockResponsibilitiesOdellClassificationShlaer MellorObject lifecyclesRumbaughOMTBoochBooch methodJacobsonOOSEContributions to the UML33 Overview of the UMLThe UML is a language forvisualizingspecifyingconstructingdocumentingthe artifacts of a softwareintensive system34 Overview of the UMLModeling elementsRelationshipsExtensibility MechanismsDiagrams35 Modeling ElementsStructural elementsclass, interface, collaboration, use case, active class, component, nodeBehavioral elementsinteraction, state machineGrouping elementspackage, subsystemOther elementsnote36 RelationshipsDependencyAssociationGeneralizationRealization37 Extensibility MechanismsStereotypeTagged valueConstraint38 Models, Views, and DiagramsUse CaseDiagramsUse CaseDiagramsUse CaseDiagramsScenarioDiagramsScenarioDiagramsCollaborationDiagramsStateDiagramsStateDiagramsComponentDiagramsComponentDiagramsComponentDiagramsDeploymentDiagramsStateDiagramsStateDiagramsObjectDiagramsScenarioDiagramsScenarioDiagramsStatechartDiagramsUse CaseDiagramsUse CaseDiagramsSequenceDiagramsStateDiagramsStateDiagramsClassDiagramsActivityDiagramsA model is a completedescription of a systemfrom a particularperspectiveModels39 DiagramsA diagram is a view into a modelPresented from the aspect of a particular stakeholderProvides a partial representation of the systemIs semantically consistent with other viewsIn the UML, there are nine standard diagramsStatic views: use case, class, object, component, deploymentDynamic views: sequence, collaboration, statechart, activity40 Use Case DiagramCaptures system functionality as seen by users41 Use Case DiagramCaptures system functionality as seen by usersBuilt in early stages of developmentPurposeSpecify the context of a systemCapture the requirements of a systemValidate a systems architectureDrive implementation and generate test casesDeveloped by analysts and domain experts42 Class DiagramCaptures the vocabulary of a system43 Class DiagramCaptures the vocabulary of a systemBuilt and refined throughout developmentPurposeName and model concepts in the systemSpecify collaborationsSpecify logical database schemasDeveloped by analysts, designers, and implementers44 Object DiagramCaptures instances and links45 Object DiagramShows instances and linksBuilt during analysis and designPurposeIllustrate data/object structuresSpecify snapshotsDeveloped by analysts, designers, and implementers46 Component DiagramCaptures the physical structure of the implementation47 Component DiagramCaptures the physical structure of the implementationBuilt as part of architectural specificationPurposeOrganize source codeConstruct an executable releaseSpecify a physical databaseDeveloped by architects and programmers48 Deployment DiagramCaptures the topology of a systems hardware49 Deployment DiagramCaptures the topology of a systems hardwareBuilt as part of architectural specificationPurposeSpecify the distribution of componentsIdentify performance bottlenecksDeveloped by architects, networking engineers, and system engineers50 Sequence DiagramCaptures dynamic behavior (timeoriented)51 Sequence DiagramCaptures dynamic behavior (timeoriented)PurposeModel flow of controlIllustrate typical scenarios52 Collaboration DiagramCaptures dynamic behavior (messageoriented)53 Collaboration DiagramCaptures dynamic behavior (messageoriented)PurposeModel flow of controlIllustrate coordination of object structure and control54 Statechart DiagramCaptures dynamic behavior (eventoriented)55 Statechart DiagramCaptures dynamic behavior (eventoriented)Purpose Model object lifecycleModel object lifecycle Model reactive objects (user interfaces, Model reactive objects (user interfaces, devices, etc.)devices, etc.)56 Activity DiagramCaptures dynamic behavior (activityoriented)57 Activity DiagramCaptures dynamic behavior (activityoriented)PurposeModel business workflowsModel operations58 Architecture and the UMLOrganizationPackage, subsystemDynamicsInteractionState machineDesign ViewImplementation ViewProcess ViewComponents Classes, interfaces,collaborationsActive classesDeployment ViewNodesUse Case ViewUse cases59 Software engineering processA set of partially ordered steps intended to reach a goal. In software engineering the goal is to build a software product or to enhance an existing one.Architectural processSequence of activities that lead to the production of architectural artifacts:A software architecture descriptionAn architectural prototype60 Rational Unified ProcessIterativeArchitecturecentricUsecase drivenRisk confronting61 Focus over timeDiscoveryInventionFocusImplementation62 Key conceptsPhase, IterationsProcess WorkflowsActivity, stepsArtifactsmodelsreports, documentsWorker: ArchitectWhat does What does happen?happen?What is What is produced?produced?Who does Who does it?it?When does When does architecture happen?architecture happen?63 Lifecycle PhasestimeInceptionElaborationConstructionTransition Inception Define the scope of the project and develop business case Elaboration Plan project, specify features, and baseline the architecture Construction Build the product Transition Transition the product to its users64 Major MilestonestimeVision Baseline Architecture InitialCapability Product ReleaseInceptionElaborationConstructionTransition65 Phases and IterationsAn iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable releaseArchIteration.Dev IterationDev Iteration.TransIteration.ReleaseRelease Release ReleaseReleaseReleaseReleaseReleasePrelimIteration.InceptionElaborationConstructionTransition66 Architecture-CentricModels are vehicles for visualizing, specifying, constructing, and documenting architectureThe Unified Process prescribes the successive refinement of an executable architecturetimeArchitectureInceptionElaborationConstructionTransition67 Unified Process structureManagementEnvironmentBusiness ModelingImplementationTestAnalysis & DesignPreliminary Iteration(s) Iter.#1PhasesProcess WorkflowsIterationsSupporting Workflows Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1DeploymentConfiguration MgmtRequirementsElaborationTransitionInceptionConstruction68 Architecture and IterationsUse caseModelDesignModelDeploymentModelTestModelImplementationModelContent69 Architectural designIdentify, select, and validate “architecturally significant” elementsNot everything is architectureMain “business” classesImportant mechanismsProcessors and processesLayers and subsystemsInterfacesProduce a Software Architecture Documen70 Architectural design workflowSelect scenarios: criticality and riskIdentify main classes and their responsibilityDistribute behavior on classesStructure in subsystems, layers, define interfacesDefine distribution and concurrencyImplement architectural prototypeDerive tests from use casesEvaluate architectureIterateUse case viewLogical viewDeployment viewImplementation viewProcess view71 Sources of architectureTheftMethodIntuitionClassical systemUnprecedented systemTheftMethodIntuition72 PatternsA pattern is a solution to a problem in a contextA pattern codifies specific knowledge collected from experience in a domainAll wellstructured systems are full of patternsIdiomsDesign patternsArchitectural patterns73 MechanismsScrews BrakesKeys PipesRivets ValvesBearings SpringsPins, axles, shafts Cranks and rodsCouplings CamsRopes, belts, and chains PulleysFriction wheels Engaging gearsToothed wheelsFlywheelsLevers and connecting rodsClick wheels and gearsRatchetsdaVinci74 Design patternsCreational patternsAbstract factoryPrototypeStructural patternsAdapterBridgeProxyBehavioral patternsChain of responsibilityMediatorVisitorMechanisms are the soul of an architectureDesign PatternsGamma et al75 Modeling a design pattern76 Modeling a design pattern (cont.)77 Modeling a design pattern (cont.)78 Architectural patternsDistributed LayeredEventdriven MVCFramebased IRcentricBatch SubsumptionPipes and filters DisposableRepositorycentricBlackboardInterpreterRulebasedSoftware ArchitectureShaw and GarlanBuschmann et alA System of PatternsBuschman et alBooch79 Complex business systemReal-Life Object-oriented SystemsSoren Lauesen80 Logical application architectureRelationalDatabaseGraphicalUserInterfaceRelationalDatabaseGraphicalUserInterfaceBusinessObjectModelGraphicalUserInterfaceBusinessObjectModelRelationalDatabase81 Physical application architectureRelational Database Server(s)Client CWWW BrowserWebServerHTMLCGIASPJavaBusiness ObjectServicesBusiness ObjectEngineApplicationBusiness ObjectServicesClient ABusiness ObjectEngineThinner client, thicker serverClient BApplicationBusiness ObjectServicesBusiness ObjectEngineBusiness Object ServerDCOMADO/RCORBABeansCOMMTSBeansETS82 Complex Internet systemThe Second WavePaul Dreyfus, NetscapeClientServerApplicationServerFulfillmentSystemFinancialSystemInventorySystemRDBMSServerDynamic HTML, JavaScript, Javaplug-ins, source code enhancementsJava, C, C+, JavaScript, CGIJava, C, C+, JavaBeans, CORBA, DCOMNative languages83 Who are the architects?Experiencesoftware developmentdomainProactive, goal orientedLeadership, authorityArchitecture teambalance84 ArchitectNot just a top level designerNeed to ensure feasibilityNot the project managerBut “joined at the hip”Not a technology expertPurpose of the system, “fit”, Not a lone scientistCommunicator85 Software architecture team charterDefining the architecture of the softwareMaintaining the architectural integrity of the softwareAssessing technical risks related to the software designProposing the order and contents of the successive iterations Consulting servicesAssisting marketing for future product definitionFacilitating communications between project teams86 Architecture is making decisionsThe life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.87 FuturesADL: Architecture Description LanguagesUML, UniCon, LILEAnna, P+, LEAP, Wright, RapidStandardization of conceptsIEEE Working Group on ArchitectureINCOSE Working Group on System ArchitectureSystematic capture of architectural patterns88 References (Architecture)Len Bass, Paul Clements & Rick Kazman, Software Architecture in Practice, Addison-Wesley, 1998.Frank Buschmann, Rgine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl, Pattern-Oriented Software Architecture - A System of Patterns, Wiley and Sons, 1996.Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software Architecture, Addison-Wesley 1999.Eric Gamma, John Vlissides, Richard Helm, Ralph Johnson, Design Patterns, Addison-Wesley 1995.Philippe Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, 12 (6), November 1995, IEEE. http:/www.rational.com/support/techpapers/ieee/Eberhardt Rechtin, Systems Architecting: Creating and Building Complex Systems, Englewood Cliffs NJ, Prentice-Hall, 1991. 89 References (Architecture)Eberhardt Rechtin & Mark Maier, The Art of System Architecting, CRC Press, 1997.Recommended Practice for Architectural Description, Draft 2.0 of IEEE P1471, May 1998http:/www.pithecanthropus.com/awg/Mary Shaw, and David Garlan, Software ArchitecturePerspectives on an Emerging Discipline, Upper Saddle River, NJ, Prentice-Hall, 1996.Bernard I. Witt, F. Terry Baker, and Everett W. Merritt, Software Architecture and DesignPrinciples, Models, and Methods, New York NY, Van Nostrand Reinhold, 1995.The World-wide Institute of Software Architectshttp:/www.wwisa.org90 References (UML)Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.91 References (Process)Barry Boehm, “A spiral model of software development and enhancement,” IEEE Computer, May 1998.Barry Boehm, “Anchoring the software process,” IEEE Software, July 1996.Grady Booch, Object Solutions, Addison-Wesley, 1995.Philippe Kruchten, “A Rational Development Process,” CrossTalk, July 1996.http:/www.rational.com/support/techpapers/devprcs/Philippe Kruchten, The Rational Unified Process - An Introduction, Addison-Wesley, 1999.Rational Unified Process 5.0, Rational, Cupertino, CA, 1998Walker Royce, Software Project Management: a Unified Framework, Addison-Wesley, 1998The Software Program Managers Networkhttp:/www.spmn.com个人观点供参考，欢迎讨论