軟件系統(tǒng)設(shè)計與體系結(jié)構(gòu)：Ch4 Software Architecture Descriptions

1、Ch 4 Software Architecture DescriptionsSoftware System Design and Architecture描述軟件體系結(jié)構(gòu)Main ContentsModeling and Documenting Software Architecture“Architectural Blueprints The “4+1” View Model of Software Architecture”UML描述示例What do We Model?Basic architectural elementsComponentsConnectorsInterfacesC

2、onfigurationsRationale reasoning behind decisions？4Model Methods of Software ArchitecturesBox-LineFormal LanguagesUMLModel Methods of Software Architecturescurrent practice for documenting software architectures is commonly informal and in many cases based in box-and-line notations.Major disadvantag

3、es of Box-LineAmbiguity in the descriptions. Lack of support for detecting inconsistencies.Inability to establish traceability between design and code.Architectural details incompleteness (most of the times reverse engineering is needed to detect them).Formal LanguageArchitecture Description Languag

4、esThe positivesADLs represent a formal way of representing architectureADLs are intended to be both human and machine readableADLs support describing a system at a higher level than previously possibleADLs permit analysis of architectures completeness, consistency, ambiguity, and performanceThe nega

5、tivesThere is not universal agreement on what ADLs should represent, particularly as regards the behavior of the architectureMost ADL work today has been undertaken with academic rather than commercial goals in mindMost ADLs tend to be very vertically optimized toward a particular kind of analysisAD

6、LsEarly architecture description languagesDarwinRapideWrightDomain- and style-specific languagesKoalaWeavesAADLExtensible architecture description languagesAcmeADMLxADLWright Example10Component DataStore Port getValues (behavior specification) Port storeValues (behavior specification) Computation (b

7、ehavior specification)Component Calculation Port getValues (behavior specification) Port storeValues (behavior specification) Port calculate (behavior specification) Computation (behavior specification) Component UserInterface Port getValues (behavior specification) Port calculate (behavior specific

8、ation) Computation (behavior specification)Connector Call Role Caller = Role Callee = Glue = Wright Example11Component DataStore Port getValues (behavior specification) Port storeValues (behavior specification) Computation (behavior specification)Component Calculation Port getValues (behavior specif

9、ication) Port storeValues (behavior specification) Port calculate (behavior specification) Computation (behavior specification) Component UserInterface Port getValues (behavior specification) Port calculate (behavior specification) Computation (behavior specification)Connector Call Role Caller = Rol

10、e 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.storeValue

11、s as CtoUIstoreValues.Callee UI.calculate as UItoC.Caller C.calulate as UItoC.Callee UI.getValues as UItoDS.Caller DS.getValues as UItoDS.CalleeEnd LunarLander.Acme Example12/Global TypesProperty Type returnsValueType = bool;Connector Type CallType = Roles callerRole; calleeRole; ; Property returnsV

12、alue : returnsValueType; ;System LunarLander = /Components Component DataStore = Ports getValues; storeValues; ; Component Calculation = Ports calculate; getValues; storeValues; ; Component UserInterface = Ports getValues; calculate; ; / Connectors Connector UserInterfaceToCalculation : CallType Rol

13、es callerRole; calleeRole; ; Property returnsValue : returnsValueType = true; Connector UserInterfaceToDataStore : CallType Roles callerRole; calleeRole; ; Property returnsValue : returnsValueType = true; Acme Example13/Global TypesProperty Type returnsValueType = bool;Connector Type CallType = Role

14、s callerRole; calleeRole; ; Property returnsValue : returnsValueType; ;System LunarLander = /Components Component DataStore = Ports getValues; storeValues; ; Component Calculation = Ports calculate; getValues; storeValues; ; Component UserInterface = Ports getValues; calculate; ; / Connectors Connec

15、tor UserInterfaceToCalculation : CallType Roles callerRole; calleeRole; ; Property returnsValue : returnsValueType = true; Connector UserInterfaceToDataStore : CallType Roles callerRole; calleeRole; ; Property returnsValue : returnsValueType = true; Connector CalculationToDataStoreS : CallType Roles

16、 callerRole; calleeRole; ; Property returnsValue : returnsValueType = false; Connector CalculationToDataStoreG : CallType Roles callerRole; calleeRole; ; Property returnsValue : returnsValueType = true; Attachments UserInterface.getValues to UserInterfaceToDataStore.callerRole; UserInterfaceToDataSt

17、ore.calleeRole to DataStore.getValues; UserInterface.getValues to UserInterfaceToDataStore.callerRole; UserInterfaceToDataStore.calleeRole to DataStore.getValues; UserInterface.calculate to UserInterfaceToCalculation.callerRole; UserInterfaceToCalculation.calleeRole to Calculation.calculate; Calcula

18、tion.storeValues to CalculationToDataStoreS.callerRole; CalculationToDataStoreS.calleeRole to DataStore.storeValues; Calculation.getValues to CalculationToDataStoreG.callerRole; CalculationToDataStoreG.calleeRole to DataStore.getValues; ; For More InformationACME: /acmeRapide: /rapide/Wright: /afs/c

19、s/project/able/www/wright/index.htmlAesop: /afs/cs/project/able/www/aesop/aesop_home.htmlUnicon: /afs/cs/project/vit/www/unicon/index.htmlC2 SADL: /pub/arch/SSEP: /projects/ssepp ADML: /projects/ssepp/admlUML the Unified Modeling LanguageThe most popular ADL in practice together with “4+1”Advantages

20、Support for a diverse array of viewpoints focused on many common software engineering concernsUbiquity improves comprehensibilityExtensive documentation and tool support from many vendorsDisadvantagesNeeds customization through profiles to reduce ambiguity15Main ContentsModeling and Documenting Soft

21、ware Architecture“Architectural Blueprints The “4+1” View Model of Software Architecture”UML描述示例Multi-Viewpoint Model of IEEE Adapted from “IEEE Recommended Practice for Architectural Description of Software Intensive Systems”. IEEE (2000)Multi-Viewpoint Model of IEEE IEEE 1471 Core Conceptsstakehol

22、derAn individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a systemConcerns Interests which pertain to the systems development, its operation or any other aspects that are critical or otherwise important to one or more stakeholdersView A representation o

23、f a whole system from the perspective of a related set of concernsViewpointA specification of the conventions for constructing and using a viewA pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and ana

24、lysisArchitecture (informational)the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolutionAbout KruchtenPhilippe KruchtenOver 16 years of experience as the leader of RUP developme

25、nt team in Rational corp. (now owned by IBM)Valuable experiences in industry (Telecom, Air traffic control system) which he used them for confirmation of his model194+1 View Model of Architecture20Logical viewPhysical ViewProcess ViewDevelopment viewEnd userSystem EngineerIntegratorProgrammers& soft

26、ware managersScenariosLogical View (Object-oriented Decomposition)The system is decomposed into a set of key abstractions, taken (mostly) from the problem domain, in the form of objects or object classesComponent, connector, configuration betterViewer: End-userconsiders: Functional requirements- Wha

27、t the system should provide in terms of services to its users. This decomposition is not only for the sake of functional analysis, but also serves to identify common mechanisms and design elements across the various parts of the system21Logical view Example22邏輯視圖部件類型可以用以構(gòu)造型component擴展了的類來描述可以擁有端口連接件

28、類型可以用以構(gòu)造型 connector 擴展了的類來描述用類的端口來描述角色用構(gòu)造型Property擴展屬性來描述特征component類中的Property屬性用來描述部件的特征connector類中的Property屬性用來描述連接件的特征邏輯視圖用對象圖描述配置為部件類型建立行為狀態(tài)圖，描述部件類型的詳細功能規(guī)格；為連接件類型建立行為狀態(tài)圖，描述連接件類型的交互機制；為端口/角色建立協(xié)議狀態(tài)機，描述部件端口和連接件角色的交互協(xié)議；為配置和復(fù)合類型建立順序圖，描述配置和復(fù)合類型所包含的功能規(guī)格。Development View (Subsystem decomposition) Basis

29、 of a line of productThe development architecture of the system is represented by module and subsystem diagrams, showing the export and import relationships.Viewer: Programmers and Software Managersconsiders: software module organization (Hierarchy of layers, software management, reuse, constraints

30、of tools)Style: layered style25Development View Example開發(fā)視圖UML的構(gòu)件圖（Component Diagram）可以用來描述軟件體系結(jié)構(gòu)實現(xiàn)模塊的組織；以UML提供的構(gòu)造型subsystem，可以描述實現(xiàn)模塊的子系統(tǒng)組織和分層組織Process View (The process decomposition)viewer: Integratorsconsiders: Non - functional requirements (concurrency, performance, scalability)style: Several st

31、yles would fit in this view (Garlan and Shaw s Architecture styles)28Process view (cont.)Uses multiple levels of abstractions, a logical network of processes at the highest level A process is a grouping of tasks that form an executable unit:The software is partitioned into a set of independent tasks

32、 Major Tasks: Arch. relevant tasksMinor Tasks: Helper tasks. (Buffering)29Process View example30進程視圖UML定義的主動類（Active Class）可以用來描述進程利用UML的順序圖，可以更詳細地描述進程之間的通信機制給出 邏輯視圖/開發(fā)視圖 與進程視圖的映射表Physical View (Mapping the software to the Hardware)Topology, Communication)The various elements identified networks, pr

33、ocesses, tasks, and objectsneed to be mapped onto the various nodes. We expect that several different physical configurations will be usedViewer: System EngineersConsiders: Non-functional req. regarding to underlying hardware (availability, reliability (fault-tolerance), performance (throughput), an

34、d scalability)32Physical view example (cont.)33部署視圖用UML部署視圖描述體現(xiàn)進程的部署體現(xiàn)開發(fā)構(gòu)件的部署Scenarios (Putting it all together)The elements in the four views are shown to work together seamlessly by the use of a small set of important scenariosViewer: All users of other views and Evaluators.Considers: System consi

35、stency, validityHelp Architect during the architecture design Help illustrate and validate the document35Scenario example36The controller of Joes phone detects and validate the transition from on-hook to off-hook and sends a message to wake up the corresponding terminal object.The terminal allocates

36、 some resources, and tells the controller to emit some dial-tone.The controller receives digits and transmits them to the terminal.The terminal uses the numbering plan to analyze the digit flow.When a valid sequence of digits has been entered, the terminal opens a conversationCorrespondence between

37、views Views are interconnected. Start with Logical view (Req. Doc) and Move to Development or Process view and then finally go to Physical view. 374+1 View Model of Architecture38Logical viewPhysical ViewProcess ViewDevelopment viewEnd userSystem EngineerIntegratorProgrammers& software managersScena

38、riosFrom Logical to developmentThey are very close, but the larger the project, the greater the distanceA class (Component) is usually implemented as a module, Large classes(Component) are decomposed into multiple packagesPackage design principles needed!Grouping to subsystems based on:team organiza

39、tion, expected magnitude of code (typically 5K to 20K SLOC per subsystem), degree of expected reuse and commonality, and strict layering principles (visibility issues), release policy and configuration management.39From logical to Process viewTwo strategy to analyse level of concurrency: Inside-out:

40、 starting from Logical structuredefine agent tasksObjects executed on that same agent; several classes that need to be executed in mutual exclusionOutside-in: starting from physical structureidentify external stimuli (requests) to the system, define client and servers processes; define the right set

41、 of servers, and allocate objects to the client and servers agents; 40From development/process to physicalPackages( Processes) are mapped onto the available physical hardware, in various configurations for testing or deploymentThe Iterative processNot all software arch. Need all views.A scenario-dri

42、ven approach to develop the systemDocumentation:Software architecture documentSoftware design guidelines42RemarksMethodology successfully used in the industryAir Traffic ControlTelecomComprehensive: All other views are reducible to one of the 4 views 43Main ContentsModeling and Documenting Software Architecture“Architectural Blueprints The “4+1” View Model of Software Architecture”UML描述示例有一個軟件開發(fā)企業(yè)想在其局域網(wǎng)內(nèi)建立一個資源管理系統(tǒng)，現(xiàn)狀如下：公司每天都要做大量的代碼處理工作：簡單的語言互轉(zhuǎn)（例如將Java轉(zhuǎn)換為C+，或者反之），各種語言程序的自動集成與測試，對不同語言進行切片等程序分析，進行編碼的轉(zhuǎn)換（Un