11Architecture and Design Intent© 2006, Dewayne E PerryLecture 12EE 382VIntro to Architecture Intent and RationaleMatthew J. HawthorneENS 509B2Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VSoftware Architecture ReviewÎ Architecture = {Elements, Form, and Rationale}ªPerry-Wolf ’89, ’92Î Elementsª{Components, Connectors}Î FormªStructure of: {Components, Connectors}Î RationaleªReasons for selecting: {Elements, Form}3Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VSoftware Architecture ReviewÎ Elements and FormªThe “What” of the ArchitectureÎ RationaleªThe “Why” of the ArchitectureÎ Focus on Elements, FormªComponents and ConnectorsªArchitecture Descriptions¾ ADLs, UML, etc.¾ IDEsªImplementation Domain ConcernsÎ RationaleªImplicitªInformalªPost-priori4Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationaleÎ Some effects of “missing” RationaleªLack of traceability from Requirements to Architecture¾ Difficult to ensure a given Architectural Design fulfills a given set of Functional Intent as defined in the system Requirements¾ Impossible to reason about optimality or other qualities of Architectural DesignªLack of traceability from Architectural Elements to Requirements¾ Difficult to match candidate Architectural Elements to Requirements (e.g., open source or COTS components that could be incorporated into the Architecture)25Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale-Based ArchitectureÎ Goal: Use Rationale as the core concept directing Architectural DesignÎ Current approachesªArchitectural Styles and Patterns¾ Generalized {Element, Form} schemes to handle Implementation Domain concerns (e.g., Client-Server, Layered/N-Tier, Service-Oriented Architectures (SOA), etc.)ªIntermediate Decision-based Models and Views between Requirements and Architecture¾ Create an intermediate model between Requirements and Architecture (e.g., Grunbacher04, Jansen05)¾ Capture Architectural Design Decisions6Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale as Basis for ArchitectureIntuition:Î Requirements define Functional Intent of systemÎ Desired system Functionality (i.e., Functional Intent) should form the basis for system architectureÎ Issues, e.g.:ªImpedance mismatches between units of FI and AEsª1:N, granularity mismatches, etc.Î Rationale forms the basis for logically valid mappings/transformations from Functional Intent to Architectural Intent, as expressed by sets of Architectural Entities (AEs, i.e., Components and Connectors)7Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale-Based Architecture:Theoretical BasisTransformation from Goals (G) to Arch. Elements (E)Î Foreach ({Gi}, {Ei}), Trans({Gi} {Ei})Form: Mapping sets of Constraints (C) and inter-Element Relations (R) to sets of Elements (E)Foreach ({Ci}, {Ri}):Î Map ({Ci} {Ei})Î Map ({Ri} {Ei})Given sets of (E, C, R, and Mappings, M):ÎForm= (E, C, R, M)8Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VTheoretical BasisÎ Rationale: Logical reasoning behind mappings from a set of Goals and Constraints in the problem domain to a set of Elements and Forms in the Architectural Domain (i.e., the HL system design)Î Rationale usesªSets of Goals (G), Constraints (C) & their relations (R) ªFormal Rationale Models (Mr) & domain-specific factors (D) Î to derive/justifyªtransformations into Arch. Elements (E) and Form (F):ÎMap{Gi, Ci, Ri, Mri, Di} {Ei, Fi}39Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VTheoretical BasisÎRationale= (G, C, R, M,Mr, D,Ia)Î WhereªG = set of GoalsªC = set of ConstraintsªR = set of RelationsªM = set of MappingsªMr = set of Rationale ModelsªD = set of Domain-specific conditionsªIa = set of Architectural Intent (reasons for Mappings)10Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale TransformationsÎ Direct Functional Mapping (1:1)ªMap a unit of Functional Intent (FI) to a single Architectural Entity (AE)FI AEÎ Reason = Functional IntentÎ Constraint = AE.FI = FI11Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale TransformationsÎ Functional Decomposition (1:N)ªDecompose a unit of Functional Intent into N lower-levelArchitectural Entitiesª“Vertical” decomposition (e.g., N-Tier architectures)FI AEÎ Reason = Excessive Func. Intent / Diverse ConcernsÎ Constraint = AE.FI = ∑FIi.FI; AE.FI = FIAElayer-1AElayer-112Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale TransformationsÎ Separation of Concerns (1:M+N)ªSeparate a unit of Functional Intent into M peer + N lower-level Architectural Entities (M>=0, N>=0)ª“Vertical” (e.g., N-Tier) and/or “horizontal” (e.g., P2P/SOA) decompositionFI AE Reason = Diversity of Concerns Constraint = ∑AE.FI = FI; AEpeerAElayer-1413Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale TransformationsÎ Spatial Mapping (1:M+N)ªMap Functional Intent based on Spatial/Geographical requirementsª“Horizontal” division of FIªE.g.: Client-server, peer-to-peer, web servicesFI AE Reason = Geographic distribution of functionality Constraint = AE.loc=AE.FI.loc; ∑AE.FI/loc=∑FI/loc; AElocA locBloc=A,B14Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale TransformationsÎ Resource Sharing / Data-Layer IntegrationªMap Functional Intent based on shared resources (e.g., DB)ª“Horizontal” or “vertical” division of FIªE.g.: Client-(DB)server, peer-to-peer, web servicesFI AE Reason = Integration +Separation of Concerns Constraint = AEDBuser.use(AEDB)AEDBuser DBUseSharedDB15Architecture and Design IntentLecture 12-13© 2006, Matthew J. Hawthorne and Dewayne E Perry EE 382VRationale TransformationsÎ Functional Relation MappingªMap logical relations between units of Functional Intent to logically equivalent relations between Architectural