軟件需求分析課件：Chap 13-Architectural Analysis

1、Elaboration Iteration 3-Intermediate TopicsCh33. Architectural AnalysisCh34. Logical Architecture RefinementCh37. UML Deployment and Component DiagramsCh39. Documenting Architecture: UML & the N+1 View Model1Chapter 33. Architectural AnalysisObjectivesCreate architectural factor tables.Create techni

2、cal memos that record architectural decisions.2IntroductionArchitectural analysis can be viewed as a specialization of requirements analysis, with a focus on requirements that strongly influence the architecture. Eg. highly-secure systemThe essence of architectural analysis is to identify factors th

3、at should influence the architecture, understand their variability and priority, and resolve them.benign neglectfancy designsthird-party products3Process: When Do We Start Architectural Analysis?In the UP, architectural analysis should start even before the first development iteration, as architectu

4、ral issues need to be identified and resolved in early development work. This important topic was deferred until this point of the book so that fundamentals of OOA/D could be first presented4Definition: Variation and Evolution PointsVariation point Variations in the existing current system or requir

5、ements,such as the multiple tax calculator interfaces that must be supported.Evolution point Speculative points of variation that may arise in the future, but which are not present in the existing requirements.5Architectural AnalysisIdentification and resolution of the systems non-functional require

6、ments , in the context of the functional requirementsIdentifying variation points and the most probable evolution points.Issues at an architectural levelHow do reliability and fault-tolerance requirements affect the design?How do the adaptability and configurability requirements affect the design?Ho

7、w do the licensing costs of purchased subcomponents affect profitability?How does brand name and branding affect the architecture?6Common Steps in Architectural AnalysisArchitectural investigation (identification)Identify and analyze the non-functional requirements that have an impact on the archite

8、cture. Architectural factors (architectural drivers)Architectural design (resolution)Analyze alternatives and create solutions that resolve the impactArchitectural decisions7Identification and Analysis of Architectural FactorsArchitectural FactorsIn the UP, architecturally significant requirementsFU

9、RPS+ requirementsUsually the non-functional quality attributes (such as reliability or performance)Quality ScenariosDefine measurable (or at least observable) responses, and thus can be verifiedQuality scenarios are short statements of the form When the completed sale is sent to the remote tax calcu

10、lator to add the taxes, the result is returned within 2 seconds most of the time, measured in a production environment under average load conditions.When a bug report arrives from a NextGen beta test volunteer, reply with a phone call within 1 working day.8Factor table9Legend: H-high. M-medium. SME-

11、subject matter expert.Factors and UP Artifacts10Use cases, along with the Vision and Supplementary Specification are an important source of inspirationResolution of Architectural FactorsThe Science of architecture is the collection and organization of information about the architectural factors, as

12、in the factor table. The art of architecture is making skillful choices to resolve these factors, in light of trade-offs, interdependencies, and prioritiesRecording Architectural Alternatives, Decisions, and Motivationtechnical memos Cunningham96issue cards HNS00architectural approach documents In t

13、he UP, the memos should be recorded in the SAD.11A sample technical memo for POS12A sample technical memo for POS(cont.)13Basic Architectural Design PrinciplesSmall-scale object design /Large-scale architectural levelLow couplingHigh cohesionProtected variation (interfaces, indirection, service look

14、up, and so forth)1415Summary of Themes in Architectural Analysis“Architectural concerns are especially related to non-functional requirements, and include an awareness of the business or market context of the application. Architectural concerns involve system-level, large-scale, and broad problems w

15、hose resolution usually involves large-scale or fundamental design decisionsArchitectural analysis involve interdependencies and trade-offsArchitecture analysis involve the generation and evaluation of alternative solutions16Architectural Information in the UP ArtifactsThe architectural factors (for

16、 example, in a factor table) are recorded in the Supplementary Specification.The architectural decisions are recorded in the SAD. Technical memos Descriptions of the architectural views.17Chapter 34. Logical Architecture RefinementObjectivesExplore more issues in logical architecture and the Layers

17、pattern, including inter-layer collaboration.Present the logical architecture for this iteration of the case studies.Apply the Facade, Observer, and Controller patterns in the context of architectural layers.18Example: NextGen Logical Architecture19Inter-Layer and Inter-Package Coupling20Inter-Layer

18、 and Inter-Package Interaction Scenarios21Collaborations with the Layers PatternTwo design decisions at an architectural levelWhat are the big parts?architectural Layers pattern How are they connected?micro-architectural design patterns such as Facade, Controller, and Observer22Simple Packages versu

19、s SubsystemsPackages or Layers conceptual groups of thingsSubsystemsBehavior and Interfaces23FacadeFor subsystems, the most common pattern of access is Facade PatternA public facade object defines the services for the subsystem, and clients collaborate with the facade, not internal subsystem compone

20、nts.A facade does not normally do its own work. Rather, it is consolidator or mediator to the underlying subsystem objects, which do the work.Provide the wrapper and single point of accessEg. POSRuleEngineFacade, PersistenceFacade 24Number of interfaces exposed to upper layers25Session Facades and t

21、he Application Layer26The Controller choices27Upward Collaboration with Observer“Downward” collaboration, access to subsystemFacade pattern“Upward” Collaboration to UI layerObserver patternUI objects implement an interface such as PropertyListener or AlarmListener, and are subscribers or listeners t

22、o events (such as property or alarm events) coming from objects in the lower layers. The lower layer objects are directly sending messages to the upper layer UI objects, but the coupling is only to the objects viewed as things that implement an interface, such as PropertyListener, not viewed as spec

23、ific GUI windows.2829Model-View Separation and Upward CommunicationHow can windows obtain information to display?Polling or Pull-from-above modelPush-from-below modelTwo common solutions:The Observer patternMaking the GUI object simply appear as an object that implements an interface such as Propert

24、yListener.A UI facade object. Adding a facade within the UI layer that receives requests from below. This is an example of adding Indirection to provide Protected Variation if the GUI changes30A UI layer UIFacade is occasionally used for push-from-below designs31Relaxed Layered CouplingStrict layere

25、d/ Relaxed layered (Transparent layered)Comments on typical coupling between layers:All higher layers have dependencies on the Technical Services and Foundations layer.It is primarily the Domain layer that has dependency on the Business Infrastructure layer.The UI layer makes calls on the Applicatio

26、n layer, which makes service calls on the Domain layer; the UI layer does not call on the Domain, unless there is no Application layer.If it is a single-process desktop application, software objects in the Domain layer are directly visible to, or passed between, UI, Application, and to a lesser exte

27、nt, Technical Services.if it is a distributed system, then serializable replicates (also known as data holder or value objects) of objects in the Domain layer are usually passed to a UI layer. In this case, the Domain layer is deployed on a server computer, and client nodes get copies of server data

28、.32SummaryPackage and SubsystemDownward CommunicationUpward Communication33Chapter 37. UML Deployment and Component DiagramsObjectivesSummarize UML deployment and component diagram notation34Deployment DiagramsIt shows the deployment of software elements to the physical architecture and the communic

29、ation (usually on a network) between physical elements.Nodedevice node (or device)execution environment node (EEN)Connection communication path3536Component DiagramsA component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. 1) that the interfaces are important2) it is modular, self-contained and replaceable.Components represent pieces that are independently purchasable and upgradeable.Artifact (component in earlier versions of the UML)373