Patterns DesignUser InterfacesPatternsWhat is a Pattern?Origin of PatternsArchitectural Example: Door PlacementAlexander’s PatternsProperties of PatternsDesign PatternsPatterns at All Levels“Software Architecture”System Design GoalsKey System Design CharacteristicsExamplesCategorizing System Designs (Shaw and Garlan)Why Categorize?Data Flow DesignPipe and FilterExample of Batch SequentialIndependent ComponentsClient-Server and FacadeParallel Communicating ProcessesObserver Design PatternEvent Systems and State Transition DiagramsVirtual machinesRepositoryA Typical Repository SystemIterator patternHypertext: Basis of the WebTed NelsonLayered ArchitectureRecapPatternsDesign13 FebruaryUser InterfacesIntroducing the BookPatternsWhat is a Pattern?A solution to a problem in a contextA structured way of representing design information in prose and diagramsA way of communicating design information from an expert to a noviceRequirement: shows when and how to applyOrigin of PatternsCame from architectureChristopher Alexander, late 70sThe Timeless Way of BuildingDescribesCommon architectural motifsHow they come together to form a cohesive, livable environmentPatterns from town planning to decorative detailArchitectural Example: Door PlacementIf room has two doors and people move through it, keep both doors at one end of the roomAlexander’s PatternsEntries have five parts: Name: A short familiar, descriptive name or phrase, usually more indicative of the solution than of the problem or context. Example: One or more pictures, diagrams, and/or descriptions that illustrate prototypical application. Context: Delineation of situations under which the pattern applies. Problem: A description of the relevant forces and constraints, and how they interact. Solution: Static relationships and dynamic rules describing how to construct artifacts in accord with the pattern, often listing several variants.What do you need to change for software?Properties of PatternsIndependent, specific, and formulated precisely enough to make clear when they apply (encapsulation)Describes how to build a realization (generativity)Identifies a solution space containing an invariant that minimizes conflict among constraints (equilibrium)Represent abstractions of empirical experience and everyday knowledge (abstraction) May be extended down to arbitrarily fine levels of detail. Like fractals, patterns have no top or bottom (openness) Hierarchically related. Coarse grained patterns are layered on top of, relate, and constrain fine grained ones (composibility) What do you need to change for software?Design PatternsAll the same benefits are true in softwareCunningham and Beck recognized in late 80sCommunity formed in early 90sThe Book:Gamma, Helm, Johnson and Vlissides, Design Patterns: Elements of Reusable Object-Oriented SoftwareDefine 23 patternsThree categories:Structural – ways to represent ensembles of informationCreational – creating complex objectsBehavioral – capturing the behavior of objectPatterns at All Levels“Software Architecture”What is an architecture?External viewWhat does that mean for software?The highest level designWe’ll refer to it as “system design” – though not consistent in the industrySystem Design Goals Extensibility: adding new featuresTradeoff of generality and timeHow might it be extended?Changeability: requirements changesSimplicity: ease of understanding and implementingEfficiency: speed and sizeKey System Design CharacteristicsCohesion degree to which communication takes place within the moduleCoupling degree to which communication takes place between modulesMin-max problem: minimize coupling while maximizing cohesionExamplesRole-playing gameDecompose into 4 modules: environment, game control, participants and artifactsHigh cohesion and couplingWhen two characters meet, all 4 modules are involvedPersonal finance applicationDecompose into user activities: accounts, bill playing, loans, investmentsLow cohesion and high couplingAccounts are pretty independentLoan payment would involve the first 3 modulesCategorizing System Designs(Shaw and Garlan)Model-View ControllerData flowsViewed as data flowing among processesIndependent componentsComponents operating in parallel and communicating occasionallyVirtual machinesTreats an application as a program written in a special-purpose languageRepositoryApplication built around dataLayered architecturesPackages of function with a strong hierarchical uses relationshipWhy Categorize?Recognize patternsReuse designsLearn from other similar applicationsReuse classesData Flow DesignData flowing among processes Two categories:Pipes and filtersFilters: processesPipes: input streamsBatch sequentialPipe and filter where input streams are batches of dataPipe and Filterfilterfilterfilterfilter filterfilterpipepipeFilters: processesPipes: input streamsExample of Batch SequentialCollectmortgage fundsAccountbalancesMortgagepoolUnsecuredpoolCollectunsecured fundsPipe: batch inputProcessesPipe and filter where input streams are batches of dataIndependent ComponentsComponents operating in parallel and communicating occasionally Three typesClient-serverBrowser-web server most familiar exampleSeparate systems with narrow interfaceSometimes expanded to three tiers (why?)Façade pattern (single unified interface)Parallel communicating processesSeveral processes executing at the same timeTypically modeled with sequence diagramsObserver pattern (one-to-many dependencies)Event systemsSet of components waiting for inputExample: word processor waiting for user inputState transition diagramsState pattern (alter behavior depending on state)Client-Server and Facade«not exposed»P«not exposed» Façade«exposed»Client12«not exposed»«not exposed»«not exposed»«not exposed»Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Key concept: limit exposed interfaceBrowser-web server most familiar example:Separate systems with narrow interfaceParallel Communicating ProcessesAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Customer:customer
View Full Document