軟件需求分析英文課件：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.)13PrioritiesThere is a hierarchy of goals that guides architectural decisionsInflexible constraints, including safety and legal compliance.The NextGen POS must correctly apply tax

14、policies.Business goalsDemo of noteworthy features ready for the POSWorld trade show in Hamburg in 18 months.Has qualities and features attractive to department stores in Europe (for example, multi-currency support and customizable business rules).All other goalsThese can often be traced back to dir

15、ectly stated business goals, but are indirect. For example, easily extendible: can add in 10 person weeks could trace to a business goal of new release every six months.141516Basic Architectural Design PrinciplesSmall-scale object design /Large-scale architectural levelLow couplingHigh cohesionProte

16、cted variation (interfaces, indirection, service lookup, and so forth)17Separation of Concerns and Localization of ImpactCross-cutting concerns are those with a wide application or influence in the systemsuch as data persistence or security.Separation of concerns is especially an architectural issue

17、 because the concerns are broad, and the solutions involve major, fundamental design choices.Modularize the concern into a separate component (for example, subsystem) and invoke its services.Use decorators.Use post-compilers and aspect-oriented technologies.18Summary of Themes in Architectural Analy

18、sis“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 whose resolution usually involves large-scale or fundamental d

19、esign decisionsArchitectural analysis involve interdependencies and trade-offsArchitecture analysis involve the generation and evaluation of alternative solutions19Architectural Information in the UP ArtifactsThe architectural factors (for example, in a factor table) are recorded in the Supplementar

20、y Specification.The architectural decisions are recorded in the SAD. Technical memos Descriptions of the architectural views.20Chapter 34. Logical Architecture RefinementObjectivesExplore more issues in logical architecture and the Layers pattern, including inter-layer collaboration.Present the logi

21、cal architecture for this iteration of the case studies.Apply the Facade, Observer, and Controller patterns in the context of architectural layers.21Example: NextGen Logical Architecture22Inter-Layer and Inter-Package Coupling23Inter-Layer and Inter-Package Interaction Scenarios24Collaborations with

22、 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 Observer25Simple Packages versus SubsystemsPackages or Layers conceptual groups of thingsSub

23、systemsBehavior and Interfaces261) FacadeFor 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 components.A facade does not normally do its own work. Rather, it

24、 is consolidator or mediator to the underlying subsystem objects, which do the work.Provide the wrapper and single point of accessEg. POSRuleEngineFacade, PersistenceFacade 27Number of interfaces exposed to upper layers28Session Facades and the Application Layer292) The Controller choices30System op

25、erations in the SSDs and in terms of layers313) Upward 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

26、 to 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 sp

27、ecific GUI windows.3233Model-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 Prope

28、rtyListener.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 changes34A UI layer UIFacade is occasionally used for push-from-below designs35Relaxed Layered CouplingStrict laye

29、red/ 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 Applicat

30、ion 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 ex

31、tent, 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 da

32、ta.36Information Systems: The Classic Three-Tier Architecture37A three-tier logical division deployed in two physical architectures38SummaryPackage and SubsystemDownward CommunicationUpward Communication39Chapter 37. UML Deployment and Component DiagramsObjectivesSummarize UML deployment and compone

33、nt diagram notation40Deployment DiagramsIt shows the deployment of software elements to the physical architecture and the communication (usually on a network) between physical elements.Nodedevice node (or device)execution environment node (EEN)Connection communication path4142Component DiagramsA com

34、ponent 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 upgradeab

35、le.Artifact (component in earlier versions of the UML)4344Chapter 39. Documenting Architecture: UML & the N+1 View ModelObjectivesCreate useful architecture documentation based on the N+1 (or 4+1) view model.Apply various UML diagram types.45The SAD and Its Architectural ViewsSAD is a summary of the

36、 architectural decisions (such as with technical memos) and the N+1 architectural views.Motivationa learning aid for developers who need to understand the essential ideas of the system.Architectural ViewA view of the system architecture from a given perspective; it focuses primarily on structure, modularity, essential components, and the main control flows.46The N+1 (or 4+1) View ModelLogicalDeploymentProcessUse caseDataSecurityImplementationDevelopment47Example: A NextGen POS SAD48Package diagram of the logical view49Deployment view50A data flow view for a Process Sale scenario51A partial us