软件需求分析课件：Chap 13-Architectural Analysis

1、Elaboration Iteration 3-Intermediate TopicspCh33. Architectural AnalysispCh34. Logical Architecture RefinementpCh37. UML Deployment and Component DiagramspCh39. Documenting Architecture: UML & the N+1 View Model1Chapter 33. Architectural Analysiso Objectiveso Create architectural factor tables.o

2、 Create technical memos that record architectural decisions.2IntroductionoArchitectural analysis can be viewed as a specialization of requirements analysis, with a focus on requirements that strongly influence the architecture. nEg. highly-secure systemoThe essence of architectural analysis is to id

3、entify factors that should influence the architecture, understand their variability and priority, and resolve them.nbenign neglectnfancy designsnthird-party products3Process: When Do We Start Architectural Analysis?oIn the UP, architectural analysis should start even before the first development ite

4、ration, as architectural issues need to be identified and resolved in early development work. oThis important topic was deferred until this point of the book so that fundamentals of OOA/D could be first presented4Definition: Variation and Evolution Pointso Variation point nVariations in the existing

5、 current system or requirements,osuch as the multiple tax calculator interfaces that must be supported.o Evolution point nSpeculative points of variation that may arise in the future, but which are not present in the existing requirements.5Architectural AnalysisoIdentification and resolution of the

6、systems non-functional requirements , in the context of the functional requirementsoIdentifying variation points and the most probable evolution points.oIssues at an architectural levelnHow do reliability and fault-tolerance requirements affect the design?nHow do the adaptability and configurability

7、 requirements affect the design?nHow do the licensing costs of purchased subcomponents affect profitability?nHow does brand name and branding affect the architecture?6Common Steps in Architectural Analysiso Architectural investigation (identification)nIdentify and analyze the non-functional requirem

8、ents that have an impact on the architecture. nArchitectural factors (architectural drivers)o Architectural design (resolution)nAnalyze alternatives and create solutions that resolve the impactnArchitectural decisions7Identification and Analysis of Architectural FactorsoArchitectural FactorsnIn the

9、UP, architecturally significant requirementsnFURPS+ requirementsnUsually the non-functional quality attributes (such as reliability or performance)oQuality ScenariosnDefine measurable (or at least observable) responses, and thus can be verifiednQuality scenarios are short statements of the form oWhe

10、n the completed sale is sent to the remote tax calculator to add the taxes, the result is returned within 2 seconds most of the time, measured in a production environment under average load conditions.oWhen a bug report arrives from a NextGen beta test volunteer, reply with a phone call within 1 wor

11、king day.8Factor table9Legend: H-high. M-medium. SME-subject matter expert.Factors and UP Artifacts10oUse cases, along with the Vision and Supplementary Specification are an important source of inspirationResolution of Architectural FactorsoThe Science of architecture is the collection and organizat

12、ion of information about the architectural factors, as in the factor table. oThe art of architecture is making skillful choices to resolve these factors, in light of trade-offs, interdependencies, and prioritiesoRecording Architectural Alternatives, Decisions, and Motivationntechnical memos Cunningh

13、am96nissue cards HNS00narchitectural approach documents nIn the UP, the memos should be recorded in the SAD.11A sample technical memo for POS12A sample technical memo for POS(cont.)13Basic Architectural Design Principleso Small-scale object design /Large-scale architectural levelnLow couplingnHigh c

14、ohesionnProtected variation (interfaces, indirection, service lookup, and so forth)1415Summary of Themes in Architectural Analysis1.“Architectural concerns are especially related to non-functional requirements, and include an awareness of the business or market context of the application. 2.Architec

15、tural concerns involve system-level, large-scale, and broad problems whose resolution usually involves large-scale or fundamental design decisions3.Architectural analysis involve interdependencies and trade-offs4.Architecture analysis involve the generation and evaluation of alternative solutions16A

16、rchitectural Information in the UP Artifactso The architectural factors (for example, in a factor table) are recorded in the Supplementary Specification.o The architectural decisions are recorded in the SAD. nTechnical memos nDescriptions of the architectural views.17Chapter 34. Logical Architecture

17、 RefinementoObjectivesoExplore more issues in logical architecture and the Layers pattern, including inter-layer collaboration.oPresent the logical architecture for this iteration of the case studies.oApply the Facade, Observer, and Controller patterns in the context of architectural layers.18Exampl

18、e: NextGen Logical Architecture19Inter-Layer and Inter-Package Coupling20Inter-Layer and Inter-Package Interaction Scenarios21Collaborations with the Layers Patterno Two design decisions at an architectural leveln What are the big parts?oarchitectural Layers pattern n How are they connected?omicro-a

19、rchitectural design patterns such as Facade, Controller, and Observer22Simple Packages versus SubsystemsoPackages or Layers nconceptual groups of thingsoSubsystemsnBehavior and Interfaces23Facadeo For subsystems, the most common pattern of access is Facade PatternnA public facade object defines the

20、services for the subsystem, and clients collaborate with the facade, not internal subsystem components.nA facade does not normally do its own work. Rather, it is consolidator or mediator to the underlying subsystem objects, which do the work.nProvide the wrapper and single point of accessnEg. POSRul

21、eEngineFacade, PersistenceFacade 24Number of interfaces exposed to upper layers25Log4JTechnical ServicesDomainUIPersistenceDBFacadeSalesRegisterSaleSwingProcessSaleFrameJessSOAPfor applications with only a few system operations, perhaps only one object acts as the facade into the layerThe Technical

22、Services layer typically exposes many interfaces-at least one per subsystemSession Facades and the Application Layer26ApplicationDomainUISalesRegisterSaleSwingProcessSaleJFrameApplication session facade objects that maintain session state and control workflow related to some work-often by use case.P

23、rocessSaleSessionFacadeProcessRentalSessionFacadeHandleReturnsSessionFacadeProcessRentalJFrame.RentalsRental.The Controller choices27ApplicationDomainUISwingProcessSaleFrameGRASP Controller pattern suggests these common choices of objects to handle system operation requests.RegistermakeNewSaleenterI

24、tem.ProcessSaleSessionFacademakeNewSaleenterItem.ORUpward Collaboration with Observero “Downward” collaboration, access to subsystemnFacade patterno “Upward” Collaboration to UI layernObserver patternnUI objects implement an interface such as PropertyListener or AlarmListener, and are subscribers or

25、 listeners to events (such as property or alarm events) coming from objects in the lower layers. nThe 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 v

26、iewed as specific GUI windows.2829: Domain:Sales:Register:Cashier: UI:Swing:ProcessSaleFrameenterItem(id, qty).enterItem(id, qty)s : Domain:Sales:SalemakeLineItem(spec, qty)Collaboration from the lower layers to the UI layer is usually via the Observer (Publish-Subscribe) pattern. The Sale object ha

27、s registered subscribers that are PropertyListeners. One happens to be a Swing GUI JFrame, but the Sale does not know this object as a GUI JFrame, but only as a PropertyListener.onPropertyEvent(s, sale.total, total).Model-View Separation and Upward Communicationo How can windows obtain information t

28、o display?nPolling or Pull-from-above modelnPush-from-below modelo Two common solutions:nThe Observer patternoMaking the GUI object simply appear as an object that implements an interface such as PropertyListener.nA UI facade object. oAdding a facade within the UI layer that receives requests from b

29、elow. 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 designs31DomainUIRegisterSaleProcessSaleJFrameUIFacadeUIFacades are occasionally used when a push-from-below communication model is required.

30、Not a Swing or GUI class. Just a plain object which adds a level of indirection to the GUI objectsRelaxed Layered CouplingoStrict layered/ Relaxed layered (Transparent layered)oComments on typical coupling between layers:nAll higher layers have dependencies on the Technical Services and Foundations

31、layer.nIt is primarily the Domain layer that has dependency on the Business Infrastructure layer.nThe UI layer makes calls on the Application layer, which makes service calls on the Domain layer; the UI layer does not call on the Domain, unless there is no Application layer.nIf it is a single-proces

32、s desktop application, software objects in the Domain layer are directly visible to, or passed between, UI, Application, and to a lesser extent, Technical Services.nif it is a distributed system, then serializable replicates (also known as data holder or value objects) of objects in the Domain layer

33、 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.32Summaryo Package and Subsystemo Downward Communicationo Upward Communication33Chapter 37. UML Deployment and Component Diagramso Objectiveso Summarize UML

34、deployment and component diagram notation34Deployment Diagramso It shows the deployment of software elements to the physical architecture and the communication (usually on a network) between physical elements.o Nodendevice node (or device)nexecution environment node (EEN)o Connection ncommunication path3536Component Diagramso A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. n1) that the interfaces are importantn2) it is modular, self-contained and replaceable.o Compo