11Architecture and Design Intent© 2006, Dewayne E PerryLecture 8EE 382VIntent via Architecture DescriptionDewayne E PerryENS 623AOffice Hours: T/Th 11:00-12:00perry @ ece.utexas.eduwww.ece.utexas.edu/~perry/education/382v-s06/2Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VModels of SW ArchitectureÎ Perry & Wolf 89/92 model of SWAÎ SWA = ( Elements, Form, Rationale )Î Elements : process, data and connectingÎ Form is the set of properties of, and relationships among, the elementsÎ Rationale is the justification for the elements and form3Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VStylesÎ An incomplete architectural prescriptionÎ Focuses on certain aspects of the architectureªarchitectural elementsªformal characteristicsªconstraints on architectural elementsªconstraints on formal characteristicsÎ Problem: Restrict the architectural structureªfor example, strict layering of the architectureÎ Solution: layered architecture styleªconstrain the interactions ¾ any interaction at elements on the same level¾ no interactions at more than one level away¾ level below: initiate interactions only¾ level above: react interactions only4Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VStylesÎ Useful rule of thumb: a style for a domainÎ Problem: multiple domains in any significant architectureÎ Challenge: integrating the styles consistently25Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VCurrent StateÎ State of Current WorkªPretty much agree about process, data and connecting elements as first class entitiesªModels differ primarily with respect to FormªFew models pay attention to rationaleªStyles tend to focus on element and form restrictionsªCurrent Î Approaches to FormªConfigurationsªTypesªPatternsªProperties6Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VCurrent StateÎ Configuration as FormªCharacterization¾ Basic box and lines approach¾ Components may be processes, subsystems, etc¾ Connections are defined by Provides/Requires clausesªApproach to Style¾ Tend not to be interested in styles¾ Except in the context of dynamic arch’sÎ Types as FormªCharacterization¾ Typically, an historical approach¾ Look for types and classes of architectural objects¾ Often organized hierarchicallyªApproach to Style¾ Emphasis on the basic classes or types of components and connectors¾ Perhaps, a slight more emphasis on connectors¾ Eg, pipes and filters; blackboard architecture7Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VCurrent StateÎ Patterns as FormªCharacterization¾ Emphasis on patterns of interactions¾ Tendency to focus on connections with components as endpointsªApproach to Style¾ Architectural instances are specializations of stylesÎProperties as FormªCharacterization¾ Properties of (or constraints on) data, process and connecting elements¾ Relationships among data, process and connecting elementsªApproach to Style¾ Selection of some critical elements¾ Selection of some properties and relationships¾ Constraints on properties and relationships8Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VProduct Line - OverviewProduct LineReference ArchitectureProduct LineProcessesAsset BaseProductProduct Architecture39Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VProduct LinesÎ Basic AspectsªBegin with product instances¾ legacy based¾ use architecture recovery processesªFocus on appropriate business domain¾ use domain specific architectural processes¾ map from recovered to domain architectureªAbstract/Generalize to Product Line ArchitectureÎ IssuesªProduct Line Reference ArchitectureªProduct Line ProcessesªAsset BaseªSupporting TechnologyªOrganizational Issues10Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VPLA Description IssuesÎ What generic features do you needÎ Relationships between PLA and PIAªDerivationªConformityªAnalysisªPlanningÎ How is evolution of PLA supportedÎ Claim: ªGeneric descriptions are necessary for product line architectural descriptions11Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VGeneric PLD ApproachesÎ Style descriptionÎ Under-constrained descriptionÎ Variance-free descriptionÎ Parametric descriptionÎ Service/provision oriented description12Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VStylesÎ SummaryªIntuitive appealªCaptures essential characteristics¾ basic components¾ minimum interactions¾ basic constraintsªIgnores variationÎ AdvantagesªMinimalist approachªAdd new products easilyªAs long as they conform to styleªSome project planning for the PLA applies to the product instance architecture (PIA)413Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VStylesÎ DisadvantagesªNot easy to refine PLA into PIA¾ by extension, additionªPLA conformity analysis requiredªWhen PLA evolves, must revalidate PIA conformanceÎ EvaluationªPossible, but not adequateªbetter uses of styles than for PLA14Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VUnder-ConstrainedÎ SummaryªDifference in completeness¾ style focus: critical features, eliminate non-essential, non-stylisticªCapture PL as completely as possibleªWith variations not ruled out by overly constraining the architectureªVariance within constraints, not within the aspects not definedÎ AdvantagesªEasier to create PIA from PLA than StylesªAnalysis at PLA level applies to PIA levelªPlanning at PLA level applies to PIA levelªEvolution via constraint relaxation easy15Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VUnder-ConstrainedÎ DisadvantgesªExtending the PLA is a significantly more constraining taskªMay not be possible to define all new products within constraintsªPLA evolution may cause conformity problemsÎ EvaluationªSeems appropriate where primary difference is something like performance where the functionality remains the sameªToo confining for variance often needed for individual products16Architecture and Design IntentLecture 8© 2006, Dewayne E Perry EE 382VVariance-FreeÎ SummaryªArchitecture is not under-constrainedªVariance is not considered architecturally important¾ product difference a design or implementation issue not an architectural one¾ eg, platform or distribution