Software Architecture and the UML
اسلاید 1: Software Architecture and the UMLGrady Booch
اسلاید 2: Architecting a dog house Can be built by one personRequiresMinimal modelingSimple processSimple tools
اسلاید 3: Architecting a houseBuilt most efficiently and timely by a teamRequiresModelingWell-defined processPower tools
اسلاید 4: Architecting a high rise
اسلاید 5: Early architectureProgress - Limited knowledge of theory
اسلاید 6: Modern architectureProgress - Advances in materials - Advances in analysisScale - 5 times the span of the Pantheon - 3 times the height of Cheops
اسلاید 7: Modeling a house
اسلاید 8: 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 - Experimentation
اسلاید 9: 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 Architect’s DataThe Handbook of Building Types
اسلاید 10: 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. - LeMessuier
اسلاید 11: Shearing layers of change SiteSkinStructureServicesSpace planStuffBrand, How Buildings Learn
اسلاید 12: 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 Royce
اسلاید 13: Forces in SoftwareTechnology churnOur enemy is complexity, and it’s 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 Microsystems
اسلاید 14: The domain of architectingArchitectureQualitiesProcessArchitecture RepresentationThe “what”The “why”The “how”The “who”SystemFeaturesArchitectureS/W RequirementsSystemQuality AttributesSatisfiesConstrainOrganizationArchitectSkillsStakeholdersDefines roleProducesFollowsDefinesTechnologyWojtek Kozaczynski
اسلاید 15: We all know that ...Architecture and design are the same thingArchitecture and infrastructure are the same thing<my favorite technology> 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 Kruchten
اسلاید 16: 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 <the ~ of the garden> b: a unifying or coherent form or structure <the novel lacks ~>Merriam Webster’s Collegiate Dictionary10th edition
اسلاید 17: 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, Rational
اسلاید 18: Architecture defined (continued)Software architecture also involvesusagefunctionalityperformanceresiliencereusecomprehensibilityeconomic and technology constraints and tradeoffsaesthetic concernsMary Shaw, CMUGrady Booch,Philippe Kruchten,Rich ReitmanKurt Bittner, Rational
اسلاید 19: 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 system’s overall properties can be determined from the properties of its partsMary Shaw, CMU
اسلاید 20: Architecture metamodel
اسلاید 21: ModelsModels are the language of designer, in many disciplinesModels are representations of the system to-be-built or as-builtModels are vehicle for communications with various stakeholdersVisual models, blueprintsScaleModels allow reasoning about some characteristic of the real system
اسلاید 22: Many stakeholders, many viewsArchitecture is many things to many different interested partiesend-usercustomerproject managersystem engineerdeveloperarchitectmaintainerother developersMultidimensional realityMultiple stakeholdersmultiple views, multiple blueprints
اسلاید 23: 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 perspective
اسلاید 24: Architecturally significant elementsNot all design is architectureMain “business” classesImportant mechanismsProcessors and processesLayers and subsystemsArchitectural views = slices through models
اسلاید 25: Characteristics of a Good ArchitectureResilientSimpleApproachableClear separation of concernsBalanced distribution of responsibilitiesBalances economic and technology constraints
اسلاید 26: Representing System ArchitectureLogical ViewEnd-user FunctionalityImplementation ViewProgrammers Software management Process ViewPerformanceScalabilityThroughput System integratorsDeployment ViewSystem topology Delivery, installationCommunicationSystem engineeringConceptualPhysicalUse Case View
اسلاید 27: Relation Between ViewsLogical viewComponent viewProcess viewDeployment view
اسلاید 28: 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 view
اسلاید 29: 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 tools
اسلاید 30: 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 partners
اسلاید 31: UML PartnersRational Software CorporationHewlett-PackardI-LogixIBMICON ComputingIntellicorpMCI SystemhouseMicrosoftObjecTimeOraclePlatinum TechnologyTaskonTexas Instruments/Sterling SoftwareUnisys
اسلاید 32: MeyerBefore and after conditionsHarelStatechartsGamma, et alFrameworks and patterns,HP FusionOperation descriptions and message numberingEmbleySingleton classes andhigh-level viewWirfs-BrockResponsibilitiesOdellClassificationShlaer - MellorObject lifecyclesRumbaughOMTBoochBooch methodJacobsonOOSEContributions to the UML
اسلاید 33: Overview of the UMLThe UML is a language forvisualizingspecifyingconstructingdocumentingthe artifacts of a software-intensive system
اسلاید 34: Overview of the UMLModeling elementsRelationshipsExtensibility MechanismsDiagrams
اسلاید 35: Modeling ElementsStructural elementsclass, interface, collaboration, use case, active class, component, nodeBehavioral elementsinteraction, state machineGrouping elementspackage, subsystemOther elementsnote
اسلاید 36: RelationshipsDependencyAssociationGeneralizationRealization
اسلاید 37: Extensibility MechanismsStereotypeTagged valueConstraint
اسلاید 38: Models, Views, and DiagramsUse CaseDiagramsUse CaseDiagramsUse CaseDiagramsScenarioDiagramsScenarioDiagramsCollaborationDiagramsStateDiagramsStateDiagramsComponentDiagramsComponentDiagramsComponentDiagramsDeploymentDiagramsStateDiagramsStateDiagramsObjectDiagramsScenarioDiagramsScenarioDiagramsStatechartDiagramsUse CaseDiagramsUse CaseDiagramsSequenceDiagramsStateDiagramsStateDiagramsClassDiagramsActivityDiagramsA model is a completedescription of a systemfrom a particularperspectiveModels
اسلاید 39: 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, activity
اسلاید 40: Use Case DiagramCaptures system functionality as seen by users
اسلاید 41: 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 system’s architectureDrive implementation and generate test casesDeveloped by analysts and domain experts
اسلاید 42: Class DiagramCaptures the vocabulary of a system
اسلاید 43: 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 implementers
اسلاید 44: Object DiagramCaptures instances and links
اسلاید 45: Object DiagramShows instances and linksBuilt during analysis and designPurposeIllustrate data/object structuresSpecify snapshotsDeveloped by analysts, designers, and implementers
اسلاید 46: Component DiagramCaptures the physical structure of the implementation
اسلاید 47: Component DiagramCaptures the physical structure of the implementationBuilt as part of architectural specificationPurposeOrganize source codeConstruct an executable releaseSpecify a physical databaseDeveloped by architects and programmers
اسلاید 48: Deployment DiagramCaptures the topology of a system’s hardware
اسلاید 49: Deployment DiagramCaptures the topology of a system’s hardwareBuilt as part of architectural specificationPurposeSpecify the distribution of componentsIdentify performance bottlenecksDeveloped by architects, networking engineers, and system engineers
اسلاید 50: Sequence DiagramCaptures dynamic behavior (time-oriented)
اسلاید 51: Sequence DiagramCaptures dynamic behavior (time-oriented)PurposeModel flow of controlIllustrate typical scenarios
اسلاید 52: Collaboration DiagramCaptures dynamic behavior (message-oriented)
اسلاید 53: Collaboration DiagramCaptures dynamic behavior (message-oriented)PurposeModel flow of controlIllustrate coordination of object structure and control
اسلاید 54: Statechart DiagramCaptures dynamic behavior (event-oriented)
اسلاید 55: Statechart DiagramCaptures dynamic behavior (event-oriented)PurposeModel object lifecycleModel reactive objects (user interfaces, devices, etc.)
اسلاید 56: Activity DiagramCaptures dynamic behavior (activity-oriented)
اسلاید 57: Activity DiagramCaptures dynamic behavior (activity-oriented)PurposeModel business workflowsModel operations
اسلاید 58: Architecture and the UMLOrganizationPackage, subsystemDynamicsInteractionState machineDesign ViewImplementation ViewProcess ViewComponents Classes, interfaces,collaborationsActive classesDeployment ViewNodesUse Case ViewUse cases
اسلاید 59: 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 prototype
اسلاید 60: Rational Unified ProcessIterativeArchitecture-centricUse-case drivenRisk confronting
اسلاید 61: Focus over timeDiscoveryInventionFocusImplementation
اسلاید 62: Key conceptsPhase, IterationsProcess WorkflowsActivity, stepsArtifactsmodelsreports, documentsWorker: ArchitectWhat does happen?What is produced?Who does it?When does 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 users
اسلاید 64: Major MilestonestimeVision Baseline Architecture InitialCapability Product ReleaseInceptionElaborationConstructionTransition
اسلاید 65: 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...ReleaseReleaseReleaseReleaseReleaseReleaseReleaseReleasePrelimIteration...InceptionElaborationConstructionTransition
اسلاید 66: Architecture-CentricModels are vehicles for visualizing, specifying, constructing, and documenting architectureThe Unified Process prescribes the successive refinement of an executable architecturetimeArchitectureInceptionElaborationConstructionTransition
اسلاید 67: 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 MgmtRequirementsElaborationTransitionInceptionConstruction
اسلاید 68: Architecture and IterationsUse case ModelDesign ModelDeployment ModelTest ModelImplementation ModelContent
اسلاید 69: Architectural designIdentify, select, and validate “architecturally significant” elementsNot everything is architectureMain “business” classesImportant mechanismsProcessors and processesLayers and subsystemsInterfacesProduce a Software Architecture Documen
اسلاید 70: 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 view
اسلاید 71: Sources of architectureTheftMethodIntuitionClassical systemUnprecedented systemTheftMethodIntuition
اسلاید 72: PatternsA pattern is a solution to a problem in a contextA pattern codifies specific knowledge collected from experience in a domainAll well-structured systems are full of patternsIdiomsDesign patternsArchitectural patterns
اسلاید 73: MechanismsScrews· BrakesKeys· PipesRivets· ValvesBearings · SpringsPins, axles, shafts· Cranks and rodsCouplings· CamsRopes, belts, and chains· PulleysFriction wheels· Engaging gearsToothed wheelsFlywheelsLevers and connecting rodsClick wheels and gearsRatchetsdaVinci
اسلاید 74: Design patternsCreational patternsAbstract factoryPrototypeStructural patternsAdapterBridgeProxyBehavioral patternsChain of responsibilityMediatorVisitorMechanisms are the soul of an architectureDesign PatternsGamma et al
اسلاید 75: Modeling a design pattern
اسلاید 76: Modeling a design pattern (cont.)
اسلاید 77: Modeling a design pattern (cont.)
اسلاید 78: Architectural patternsDistributed · LayeredEvent-driven · MVCFrame-based · IR-centricBatch · SubsumptionPipes and filters · DisposableRepository-centricBlackboardInterpreterRule-basedSoftware ArchitectureShaw and GarlanBuschmann et alA System of PatternsBuschman et alBooch
اسلاید 79: Complex business systemReal-Life Object-oriented SystemsSoren Lauesen
اسلاید 80: Logical application architectureRelationalDatabaseGraphicalUserInterfaceRelationalDatabaseGraphicalUserInterfaceBusinessObjectModelGraphicalUserInterfaceBusinessObjectModelRelationalDatabase
اسلاید 81: Physical application architectureRelational Database Server(s)Client CWWW BrowserWebServerHTMLCGIASPJavaBusiness ObjectServicesBusiness ObjectEngineApplicationBusiness ObjectServicesClient ABusiness ObjectEngineThinner client, thicker serverClient BApplicationBusiness ObjectServicesBusiness ObjectEngineBusiness Object ServerDCOMADO/RCORBABeansCOMMTSBeansETS
اسلاید 82: Complex Internet systemThe Second WavePaul Dreyfus, NetscapeClientServerApplicationServerFulfillmentSystemFinancialSystemInventorySystemRDBMSServerDynamic HTML, JavaScript, Javaplug-ins, source code enhancementsJava, C, C++, JavaScript, CGIJava, C, C++, JavaBeans, CORBA, DCOMNative languages
اسلاید 83: Who are the architects?Experiencesoftware developmentdomainPro-active, goal orientedLeadership, authorityArchitecture teambalance
اسلاید 84: 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 scientistCommunicator
اسلاید 85: 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 teams
اسلاید 86: 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 patterns
اسلاید 88: References (Architecture)Len Bass, Paul Clements & Rick Kazman, Software Architecture in Practice, Addison-Wesley, 1998.Frank Buschmann, Régine 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 Architecture—Perspectives on an Emerging Discipline, Upper Saddle River, NJ, Prentice-Hall, 1996.Bernard I. Witt, F. Terry Baker, and Everett W. Merritt, Software Architecture and Design—Principles, Models, and Methods, New York NY, Van Nostrand Reinhold, 1995.The World-wide Institute of Software Architectshttp://www.wwisa.org
اسلاید 90: 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 Manager’s Networkhttp://www.spmn.com
نقد و بررسی ها
هیچ نظری برای این پاورپوینت نوشته نشده است.