Analysis of Software Architectures
اسلاید 1: Analysis of Software Architectures
اسلاید 2: 2What Is Architectural Analysis?Architectural analysis is the activity of discovering important system properties using the system’s architectural models.Early, useful answers about relevant architectural aspectsAvailable prior to system’s constructionImportant to knowwhich questions to askwhy to ask themhow to ask themhow to ensure that they can be answered
اسلاید 3: 3Informal Architectural Models and AnalysisHelps architects get clarification from system customersHelps managers ensure project scopeNot as useful to developersSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
اسلاید 4: 4Formal Architectural Models and AnalysisSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Component UserInterface Port getValues Port calculate ComputationConnector Call Role Caller = Role Callee = Glue = Configuration LunarLander Instances DS : DataStore C : Calculation UI : UserInterface CtoUIgetValues, CtoUIstoreValues, UItoC, UItoDS : Call Attachments C.getValues as CtoUIgetValues.Caller DS.getValues as CtoUIgetValues.Callee C.storeValues as CtoUIstoreValues.Caller DS.storeValues as CtoUIstoreValues.Callee UI.calculate as UItoC.Caller C.calulate as UItoC.Callee UI.getValues as UItoDS.Caller DS.getValues as UItoDS.CalleeEnd LunarLander.Helps architects determine component composabilityHelps developers with implementation-level decisionsHelps with locating and selecting appropriate OTS componentsHelps with automated code generationNot as useful for discussions with non-technical stakeholders
اسلاید 5: 5Concerns Relevant to Architectural AnalysisGoals of analysisScope of analysisPrimary architectural concern being analyzedLevel of formality of architectural modelsType of analysisLevel of automationSystem stakeholders interested in analysis
اسلاید 6: 6Architectural Analysis GoalsThe four “C”sCompletenessConsistencyCompatibilityCorrectness
اسلاید 7: 7Architectural Analysis Goals – CompletenessCompleteness is both an external and an internal goalIt is external with respect to system requirementsChallenged by the complexity of large systems’ requirements and architecturesChallenged by the many notations used to capture complex requirements as well as architecturesIt is internal with respect to the architectural intent and modeling notationHave all elements been fully modeled in the notation?Have all design decisions been properly captured?
اسلاید 8: 8Architectural Analysis Goals – ConsistencyConsistency is an internal property of an architectural modelEnsures that different model elements do not contradict one anotherDimensions of architectural consistencyNameInterfaceBehaviorInteractionRefinement
اسلاید 9: 9Name ConsistencyComponent and connector namesComponent service namesMay be non-trivial to establish at the architectural levelMultiple system elements/services with identical namesLoose coupling via publish-subscribe or asynchronous event broadcastDynamically adaptable architectures
اسلاید 10: 10Interface ConsistencyEncompasses name consistencyAlso involves parameter lists in component servicesA rich spectrum of choices at the architectural levelExample: matching provided and required interfacesReqInt: getSubQ(Natural first, Natural last, Boolean remove) returns FIFOQueue; ProvInt1: getSubQ(Index first, Index last) returns FIFOQueue;ProvInt2: getSubQ(Natural first, Natural last, Boolean remove) returns Queue;
اسلاید 11: 11Behavioral ConsistencyNames and interfaces of interacting components may match, but behaviors need notExample: subtractionsubtract(Integer x, Integer y) returns Integer; Can we be sure what the subtract operation does? Example: QueueClient and QueueServer componentsQueueClient – getFrontprecondition q.size > 0;postcondition ~q.size = q.size;QueueServer – getFrontprecondition q.size > 1;postcondition ~q.size = q.size - 1;
اسلاید 12: 12Interaction ConsistencyNames, interfaces, and behaviors of interacting components may match, yet they may still be unable to interact properlyExample: QueueClient and QueueServer componentsSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
اسلاید 13: 13Refinement ConsistencyArchitectural models are refined during the design processA relationship must be maintained between higher and lower level modelsAll elements are preserved in the lower level modelAll design decisions are preserved in the lower-level modelNo new design decisions violate existing design decisions
اسلاید 14: 14Refinement Consistency ExampleSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
اسلاید 15: 15Architectural Analysis Goals – CompatibilityCompatibility is an external property of an architectural modelEnsures that the architectural model adheres to guidelines and constraints ofa stylea reference architecturean architectural standard
اسلاید 16: 16Architectural Compatibility Example – Lunar LanderSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. What is the style of this architecture?
اسلاید 17: 17Architectural Analysis Goals – CorrectnessCorrectness is an external property of an architectural modelEnsures that the architectural model fully realizes a system specificationthe system’s implementation fully realizes the architectureInclusion of OTS elements impacts correctnessSystem may include structural elements, functionality, and non-functional properties that are not part of the architectureThe notion of fulfillment is key to ensuring architectural correctness
اسلاید 18: 18Scope of Architectural AnalysisComponent- and connector-levelSubsystem- and system-levelBeware of the “honey-baked ham” syndromeData exchanged in a system or subsystemData structureData flowProperties of data exchangeArchitectures at different abstraction levelsComparison of two or more architecturesProcessingDataInteractionConfigurationNon-functional properties
اسلاید 19: 19Data Exchange ExampleSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
اسلاید 20: 20Architectures at Different Abstraction LevelsSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
اسلاید 21: 21Architectural Concern Being AnalyzedStructural characteristicsBehavioral characteristicsInteraction characteristicsNon-functional characteristics
اسلاید 22: 22Level of FormalityInformal modelsSemi-formal modelsFormal models
اسلاید 23: 23Type of AnalysisStatic analysisDynamic analysisScenario-driven analysisCan be both static and dynamic
اسلاید 24: 24Level of AutomationManualPartially automatedFully automated
اسلاید 25: 25Analysis StakeholdersArchitectsDevelopersManagersCustomersVendors
اسلاید 26: 26Architectural Analysis in a NutshellSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
نقد و بررسی ها
هیچ نظری برای این پاورپوینت نوشته نشده است.