Unformatted text preview:

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 InterfacesIntroducing the BookPatternsWhat is a Pattern?A solution to a problem in a contextA structured way of representing design information in prose and diagramsA way of communicating design information from an expert to a noviceRequirement: shows when and how to applyOrigin of PatternsCame from architectureChristopher Alexander, late 70sThe Timeless Way of BuildingDescribesCommon architectural motifsHow they come together to form a cohesive, livable environmentPatterns 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 PatternsIndependent, 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 PatternsAll the same benefits are true in softwareCunningham and Beck recognized in late 80sCommunity formed in early 90sThe Book:Gamma, Helm, Johnson and Vlissides, Design Patterns: Elements of Reusable Object-Oriented SoftwareDefine 23 patternsThree categories:Structural – ways to represent ensembles of informationCreational – creating complex objectsBehavioral – capturing the behavior of objectPatterns at All Levels“Software Architecture”What is an architecture?External viewWhat does that mean for software?The highest level designWe’ll refer to it as “system design” – though not consistent in the industrySystem Design Goals Extensibility: adding new featuresTradeoff of generality and timeHow might it be extended?Changeability: requirements changesSimplicity: ease of understanding and implementingEfficiency: speed and sizeKey System Design CharacteristicsCohesion degree to which communication takes place within the moduleCoupling degree to which communication takes place between modulesMin-max problem: minimize coupling while maximizing cohesionExamplesRole-playing gameDecompose into 4 modules: environment, game control, participants and artifactsHigh cohesion and couplingWhen two characters meet, all 4 modules are involvedPersonal finance applicationDecompose into user activities: accounts, bill playing, loans, investmentsLow cohesion and high couplingAccounts are pretty independentLoan payment would involve the first 3 modulesCategorizing System Designs(Shaw and Garlan)Model-View ControllerData flowsViewed as data flowing among processesIndependent componentsComponents operating in parallel and communicating occasionallyVirtual machinesTreats an application as a program written in a special-purpose languageRepositoryApplication built around dataLayered architecturesPackages of function with a strong hierarchical uses relationshipWhy Categorize?Recognize patternsReuse designsLearn from other similar applicationsReuse classesData Flow DesignData flowing among processes Two categories:Pipes and filtersFilters: processesPipes: input streamsBatch sequentialPipe 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 ComponentsComponents operating in parallel and communicating occasionally Three typesClient-serverBrowser-web server most familiar exampleSeparate systems with narrow interfaceSometimes expanded to three tiers (why?)Façade pattern (single unified interface)Parallel communicating processesSeveral processes executing at the same timeTypically modeled with sequence diagramsObserver pattern (one-to-many dependencies)Event systemsSet of components waiting for inputExample: word processor waiting for user inputState transition diagramsState 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

UNC-Chapel Hill COMP 523 - Patterns Design

Download Patterns Design
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Patterns Design and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Patterns Design 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?