Sammanfattning av denna webbsida: Dokumentationen för ett ramverk måste uppfylla flera krav. Dessa krav kan uppfyllas genom att dokumentationen struktureras som en uppsättning mönster, ibland kallade "mönsterspråk". Mönster kan beskriva syftet med ett ramverk, kan låta applikations programmerare använda ett fmework utan att behöva förstå i detalj hur det fungerar, och kan lära ut många av de designdetaljer som ingår i ramarbetet. Detta dokument visar hur man använder mönster för att dokumentera ett ramverk, och innehåller en uppsättning mönster förHotDmw som exempel. Christopher Alexander, arkitekt, utvecklade idén om ett "mönsterspråk" för att göra det möjligt för människor att utforma sina egna hem och samhällen [Alexander et. Detta beslut träder i kraft den tjugonde dagen efter det att det har offentliggjorts i Europeiska unionens officiella tidning. Ett mönsterspråk är en uppsättning mönster, som var och en beskriver hur man löser ett visst slags problem. Hans mönsterspråk börjar i mycket stor skala och förklarar hur världen bör delas upp i nationer och nationer i mindre regioner, och fortsätter med att förklara hur man kan ordna vägar, parkering, shopping, arbetsplatser, hem och platser för tillbedjan. Mönstren fokuserar på finare och finare detaljer, passerar genom en diskussion om hur man ordnar rum i ett hus, och slutligen beskriva vilken typ av material att använda för väggar, hur man dekorerar rum, och hur man ger belysning. Alexanders mönsterspråk är tänkt att vara ett dokument som icke-arkitekter kan använda för att utforma sina egna samhällen och hem. Det behövs ingen specialutbildning för att använda den. Den fokuserar på vanliga designproblem som icke-arkitekter kommer att stöta på, som hur man bygger sovrum och radhus, snarare än ovanliga sådana, som hur man bygger konsertsalar och katedraler. Även om Alexander använder termen "mönsterspråk" för att beskriva sitt dokument, är det inte ett formellt språk som ett sammanhangsfritt språk, till exempel. Ett mönsterspråk är en strukturerad uppsats, inte ett matematiskt objekt. Därför kommer vi att ersätta denna term med termen "mönster". Ett ramverk är en återanvändbar design av ett program eller en del av ett program uttryckt som en uppsättning klasser [Deutsch] [Johnson and Foote]. Liksom all programvara är det en blandning av betong och abstrakt. Eftersom ramverk är återanvändbara konstruktioner, inte bara kod, är de mer abstrakta än de flesta program, vilket gör det svårt att dokumentera dem. Ramar utformas av experter inom ett visst område och används sedan av icke-experter. Den huvudsakliga publiken av fmmetwork dokumentation är någon som vill använda ramen för att lösa typiska problem, inte någon som bygger en programvara katedral. Mönster verkar vara väl lämpade för den här publiken. Detta dokument visar ett sätt att dokumentera ramar med mönster. Det är i huvudsak ett experiment för att se hur väl mönster fungerar för att beskriva ett ramverk. Resultatet är en uppsättning mönster som ingår i bilagan. Huvudsyftet med en uppsättning mönster är att visa hur man använder ett ramverk, inte att visa hur det fungerar, men mönster kan också beskriva en hel del av teorin om dess design. En av de viktiga dragen i Alexanders mönsterspråk är dess struktur; varje mönster är skrivet i ett visst format och mönster arrangeras så att varje mönster leder in i nästa. Det format som Alexander använder är sannolikt inte lämpligt för programvara. Eftersom han till exempel bygger fysiska föremål, behöver han bilder både för att ange det problem som ett mönster löser och för att ange lösningen. Mönstren i den här tidningen har alltså ett annat format än det han använde. OOPSLA '92, s. M-i(i 63) Varje mönster beskriver ett problem som uppstår om och om igen inom ramens problemområde, och beskriver sedan hur det problemet ska lösas. Varje mönster har samma format. Det format som används i detta dokument är att först ge en beskrivning av problemet i kursiv stil. Detta följs av en detaljerad diskussion om de olika sätten att lösa problemet, med exempel och pekare på andra delar av ramen. Mönstret avslutas med en sammanfattning av lösningen, återigen kursiv, följt av pekare till andra mönster som behövs för att fylla ut och försköna den. Bilagan till detta papper beskriver en uppsättning av tio mönster för HotDraw, en ritning ram. Till exempel, mönster 4 är Den har en avgränsande låda som är oberoende av den avgränsande rutan av dess komponenter, och den kommer att visa sina komponenter endast om de är inne i dess avgränsande låda. Urvalsverktyget och textverktyget kommer att fungera på sina komponenter när vänster skiftknapp trycks. Anpassade verktyg kan fungera direkt på komponenterna, om du vill.... För att genomdriva begränsningar mellan komponenterna i en komplex figur, se Restriktioner (5). Detta mönster förutsätter att läsaren har läst andra mönster. I detta fall föregås mönster 4 av mönster 2, som definierar figurer och avgränsande rutor. Det beror också på mönster 1 för att införa PERT diagram exempel. Mönster är problemorienterade, inte lösningsorienterade. Varje mönster beskriver hur man löser en liten del av det större designproblemet. Ibland är lösningen att göra en ny underklass (t.ex. mönster 2), ibland är det att parameterisera ett objekt av en befintlig klass (t.ex. mönster lo), och ibland kräver det att ansluta flera objekt tillsammans (t.ex. mönster 3). Femwork dokumentation för ett ramverk har tre syften, och mönster kan hjälpa till att uppfylla var och en av dem. Dokumentationen skall innehålla en beskrivning av syftet med ramverket l hur ramverket skall användas l den detaljerade utformningen av ramverket. Mönster är bäst lämpade för att lära ut hur man använder ett ramverk, men vi kommer att se att en uppsättning mönster med omsorg kan uppfylla alla dessa tre syften för ramdokumentation. Ett ramverk är en återanvändbar design för lösningar på problem inom någon särskild problemdomän. Syftet med ramverket, dvs. Den problemdomän för vilken den är utformad måste vara det första som dokumentationen beskriver. Om ramverket visar sig vara olämpligt behöver läsaren inte fortsätta läsa. Den första delen bör vara liten, så att varje potentiell läsare kommer att ha tid att läsa den. Det är inte orimligt att förvänta sig att en erfaren designer kommer att ha läst den första delen av dokumentationen för varje ram som ägs av hans eller hennes organisation och på så sätt veta syftet med var och en. Detta kommer att minska problemet med att hitta rätt programvara för återanvändning. Varje mönster beskriver de problem som det är avsett att lösa. Det första mönstret för ett ramverk beskriver dess applikationsdomän. Den gör detta genom att ge exempel, liksom andra sätt att dokumentera ramar. Dessutom introducerar det första mönstret resten av mönster i språket, och det brukar berätta vilka mönster som ska vara 64 läsa nästa. Det fungerar alltså både som en katalogpost för ramverket och som en färdplan. Därefter ska dokumentationen för ett ramverk visa hur man använder det för att bygga applikationer. De flesta användare av ett ramverk vill veta så lite som möjligt om ramverket. Detta innebär att de inte är intresserade av en beskrivning av utformningen av ramverket, utan vill ha ett slags kokbok, som ger detaljerade instruktioner för att använda ramverket. Detta liknar den minimalistiska instruktionen från Caroll[Caroll] [Rosson et. Detta beslut träder i kraft dagen efter det att det har offentliggjorts i Europeiska unionens officiella tidning.], som försöker visa hur man löser särskilda problem och gör ett system användbart för en användare så snart som möjligt. för ramverk beskriver hur ramverket fungerar först, och sedan beskriver hur man använder det. Men en del av folkloren av ramar är att ingen förstår ett ramverk förrän de har använt det, så att använda det är viktigare än att läsa om teorin bakom det. Jag anser faktiskt att teorin bör följa praxis, att en diskussion om teorin bakom en ram bara är förståelig när själva ramen är förstådd, och att det bästa sättet att få en allmän förståelse av en ram är att använda den. Vi måste därför förklara hur man använder ett ramverk utan att förklara hur det fungerar. Detta är inte en ny idé; dokumentationen för MacApp har länge innehållit en kokbok [Apple] och den första dokumentationen för Model-ViewController (MVC) kallades en "Cookbook för Model-View-Controller" [Krasner och Pope]. Mönster är mer som MacApp kokbok än MVC kokbok. MCV kokbok är en samling exempel, men är fortfarande en handledning utformad för att läsas som en enhet. MacApp kokbok är en samling av "recept" med några korsreferenser, där varje recept löser ett visst problem som hur man drar ett objekt. Det inte använda sig av struktur så mycket som uppsättningen av mönster för HotDraw. Inget av dessa dokument är lika deterministiskt som en typisk kokbok, som ger algoritmer för att göra rätter, inte bara tips eller tumregler. Det tredje syftet med dokumentation för ett ramverk är att beskriva dess utformning. Detta inkluderar inte bara de olika klasserna i ramen, utan också det sätt på vilket fall av dessa klasser collabo-rate. Även om programmerare vanligtvis kan koppla ihop objekt utan att helt förstå hur de fungerar, och till och med kan göra underklasser efter en kokbok, är ett ramverk mest användbart för någon som förstår det i detalj. Den största svagheten med kokböcker är att de beskriver det typiska sättet som ramen kommer att användas på. En bra ram kommer att användas på ett sätt som dess designers aldrig tänkt sig. Därför räcker det inte med en kokbok för att beskriva varje användning av ramarbetet. Det är förmodligen därför MVC kokbok också innehåller en informell beskrivning av utformningen av ramverket, samt instruktioner om hur man använder det[ Krasner och Pope]. Å andra sidan passar någons första användning av ett ramverk vanligtvis -stereotypen av ramverkets designer, och att använda ett ramverk hjälper till att ge den intuition som behövs för att läsa en mer formell specifikation. I motsats till formella specifikationer som kontrakt [Helm et. Detta beslut träder i kraft dagen efter det att det har offentliggjorts i Europeiska unionens officiella tidning.], mönster är en informell teknik som främst syftar till att beskriva hur man använder ett ramverk, inte beskriva dess algoritmer, samarbetsmönster, eller delade invarianter. Mönster ger dock många möjligheter att beskriva en design, och det är möjligt att inkludera mycket av utformningen av en ram i mönster för den. Avsnittet mellan beskrivningen av det problem som ska lösas och sammanfattningen av lösningen går vidare på lösningen och förklarar varför det fungerar. I detta avsnitt beskrivs vanligen en del av konstruktionen av ett ramverk. Om mönstren är noggrant utformade kan de också beskriva utformningen av ett ramverk. Var ska designinformation placeras i en uppsättning mönster? I allmänhet bör detaljerad designinformation döljas så länge som möjligt för läsaren, eftersom de flesta läsare inte är intresserade av att se den. Å andra sidan är det nödvändigt att se till att mönstren innehåller informationen någonstans och att informationen inte kopieras. Tekniken som jag använde var att behandla uppsättningen mönster som en riktad graf, med referenser från ett mönster till ett annat som kanterna, och att placera designinformation så långt från det första mönstret som var möjligt. Vissa design 65 information, såsom det faktum att en HotDraw ansökan består av figurer, ritningar, handtag och verktyg, måste beskrivas i det allra första mönstret, men de flesta av det kan flyttas till efterföljande mönster utan att använda framåt referenser. Exempel spelar en nyckelroll i dokumentationen av ramverk. Exempel gör ramverken mer konkreta, gör det lättare att förstå flödet av kontroll och hjälper läsaren att avgöra om han eller hon förstår resten av dokumentationen. Exempel är också viktiga i dokumentation baserad på mönster. Både det problem som ett mönster ska lösa och dess lösning beskrivs ofta som exempel. Detta är mest uppenbart när man beskriver det ursprungliga mönstret, det som beskriver syftet med ramverket. Det är vanligtvis svårt att exakt ange en problemdomän, men en liten uppsättning exempel gör vanligtvis det allmänna området tydligt. Dessa exempel är inte avsedda att visa hur man använder ramverket för att bygga applikationer, eller att förklara utformningen av ramverket, utan snarare att visa vad ramverket är bra för. Exemplen för ett användargränssnitt kommer således att vara färdiga användargränssnitt, medan exemplen för en kompilatorram kommer att vara färdiga kompilatorer. Exemplen kommer att peka på funktioner på användarnivå som ramen tillhandahåller, men de kommer inte att förklara hur dessa funktioner tillhandahålls eller hur applikationsdesignern använder dem. Exempel kan också användas för att visa funktioner i designen. Mönstren för HotDraw använder exempel för att motivera behovet av komplexa siffror (mönster 4) och begränsningar (mönster 5). Dessa mönster börjar med exempel på HotDraw och avslutas med en diskussion om den kod som behövs för att genomföra dessa program. Exempel kan användas för att testa kör,pattems. Exemplen bör utöva alla mönster, så att någon kan se till att de lär sig alla mönster genom att testa alla exempel. De exempel som har använts för att beskriva syftet med HotDraw (dvs. Exemplen i det första mönstret) är tillräckliga för att testa alla mönster. för HotDraw användning exempel kraftigt, men HotDraw levereras med flera applikationer som visar konkreta exempel på att tillämpa ramen för ett visst problem. Att studera arbetsexempel är ett tidsfördrivet sätt att lära sig ett ramverk, och mönster är ett sätt att förstärka, uppmuntra och systematisera denna metod, inte en ersättning för den. Det är intressant att notera att exempel också spelar en nyckelroll i design (c. f use case [Jacobson] eller walk-throughs [Wirfs-Brock et. Detta beslut träder i kraft den tjugonde dagen efter det att det har offentliggjorts i Europeiska unionens officiella tidning. Detta är bara ytterligare ett exempel på den allmänna regeln att konkreta exempel är lättare att förstå än abstraktioner. Merparten av detta papper är en bilaga som innehåller ett exempel på mönster för en ram. Ramverket är HotDraw, som är ett ramverk för semantiska grafiska redaktörer som ursprungligen utvecklades på Tektronix av Kent Beck och Ward Cunningham. Det har återinförts flera gånger. Den senaste versionen, och den som mönstret beskriver, skrevs av Patrick McClaughry for ParcPlace ObjectWorks for Smalltalkrelease 4.0. Denna implementation var enklare än tidigare eftersom utformningen av användargränssnittet ramverket för Smalltalkrelease 4.0 påverkades av HotDraw. HotDraw är inte unik som en grafikredigerare ramverk. Unidraw är ett liknande ramverk för C++/X windows-miljön som är byggd på ramen för Interviews användargränssnitt [Vlissides]. DRAW-Master är en grafikredigerare ram för C++/OS 2 och Windows miljö som bygger på GUI Master application ram [Veltman och Riksen]. HotDraw är enklare och mindre kraftfull än de andra, men denna enkelhet gör det till ett bättre exempel för ett sådant här papper. Det första mönstret beskriver syftet med HotDraw. Mönstren bildar en riktad graf, med det första mönstret som ingångspunkt. Andra mönster är ordnade så att de som ligger närmast det första mönstret är de som oftast används. Till exempel beskriver det andra mönstret hur man gör underklasser av figur, vilket är något 66 som nästan varje användare av HotDraw kommer att behöva veta. Det tredje mönstret beskriver (bland annat) hur man monterar ett handtag på en figur, men det sjätte mönstret beskriver hur man gör nya typer av handtag, vilket vanligtvis är onödigt. Mönstren antar att läsaren känner till Smalltalk. Några av mönstren innehåller fragment av Smalltalk-koden. De antar också att läsaren använder Smalltalk, så de hänvisar ofta till exempel i HotDraw och antyder att läsaren snabbt kan slå upp dem med hjälp av webbläsaren. Detta tyder på att mönster skulle fungera bra med ett on-line dokumentationssystem, kanske ett som är baserat på hypertext. Mönsteruppsättningen fick sin start på workshopen "Mot en arkitekturhandbok" organiserad av Bruce Anderson på OOPSLA'91. Kent Beck och jag delade ett intresse för både HotDraw och Alexanders mönsterspråk, så vi passade på att skriva några mönster för HotDraw. Senare den hösten gav jag mönstren till några doktorander som lärde sig HotDraw, men mönstren var inte till någon hjälp. Vid den tiden var varje mönster bara ett stycke, och både exemplen och teorin om utformningen av HotDraw separerades från mönstren. Jag studerade Alexanders mönsterspråk igen, och insåg att varje mönster förlitade sig på exempel och att han gav förklaringar till sina mönster i termer av underliggande teorier om egenskaperna hos byggnadsmaterial eller social interaktion. När jag integrerade exemplen med mönster fann jag att exemplen inte illustrerade alla mönster, så jag skapade ytterligare ett eller två exempel. Jag lade tillräckligt av teorin om design i det första mönstret för att definiera det viktigaste ordförrådet och sätta resten så långt ner i mönster som möjligt, men tillräckligt långt fram för att både undvika dubblering och se till att informationen fanns innan den behövdes. Nästa grupp av människor som läste mönstren kände Smalltalk väl, men de flesta kände inte HotDraw. Deras feedback gav några förändringar, men efter några iterationer var de nöjda. Mönstren är den enda dokumentationen för en version av HotDraw som har distribuerats sedan början av 1992, och användarna säger att de är nöjda med det. Eftersom det inte finns några klagomål är det svårt att förbättra mönster, vilket visar svagheten i denna typ av informella tester. Det skulle förmodligen vara värt att prova mönster i en kontrollerad miljö där det skulle vara möjligt att titta på hur människor använder mönster och vilka aspekter av HotDraw är svårt att lära. Att skriva mönster var inte svårt när jag räknat ut formatet. Att välja bra exempel är aldrig lätt, men mönstren visade de egenskaper som de behövde visa. Förmodligen den svåraste delen av att skriva en uppsättning mönster för ett ramverk är att veta ramen tillräckligt väl för att veta hur troligt en funktion är att anpassas. Mönstrets struktur verkade hjälpa till att utforma dem. Att tänka på mönster som en riktad graf gjorde det lättare att bestämma var man ska placera exempel och designinformation, och gjorde det lättare att analysera mönster för fullständighet. Designing mönster för HotDraw tog en hel del arbete, men det bidrog också till att klargöra utformningen av ramverket, så det var en användbar övning i sig. Designing mönster kräver att analysera hur människor förväntas använda ramen, och detta pekar på sätt att använda det är obekvämt. Även om HotDraw mönster är lätta att följa på papper, mönster kan vara ännu effektivare som hypertext. Ett hypertextsystem kan göra det lättare att följa länkar till mönster, att visa fler exempel, att dölja tekniska designförklaringar från tillfälliga läsare, och att separera de olika delarna av ett mönster. Flera personer som läst tidigare versioner av denna uppsats kommenterade att mönster liknar hypertext dokumentationssystem som de har sett, även om jag har lite erfarenhet av hypertextsystem. HotDraw mönster var en imitation av Alexander mönsterspråk, inte hypertext eller MacApp kokbok. Det är intressant att slutresultatet är så likt dem. Mönster är ett bra sätt att beskriva ramar eftersom förstagångsanvändare av ett ramverk vanligtvis inte vill veta exakt hur det fungerar, men kommer bara att vara intresserad av att lösa ett visst problem. Så länge mönstren är tillräckligt kraftfulla för att beskriva de flesta första användningarna av ramverket, kommer det att uppfylla användarnas behov. En uppsättning mönster för en ram kommer att vara tillräcklig dokumentation för många av ramverkets användare. Endast de som vill gå utanför ramens vanliga gränser eller de som har ett emotionellt behov av att veta hur ramen fungerar i detalj kommer att behöva läsa traditionell designdokumentation. Den interna strukturen i en uppsättning mönster minimerar den mängd som måste läsas för att lösa ett problem, och ger också platser att sätta designinformation. Detta dokument är bara ett första steg för att skapa en metod för att dokumentera ramverk. I framtiden bör mönster testas mot andra sätt att dokumentera en ram för att se som på bästa sätt hjälper användare att bygga applikationer. Mönster bör användas för större ramar för att se om de skalas väl, även om Alexanders arbete tyder på att de kommer. Även om bara ett första steg, mönster för HotDraw i bilagan visar att mönster är en attraktiv möjlighet för att lösa problemen med att dokumentera ramar. Kent Beck och Ward Cunningham uppfann inte bara HotDraw, de introducerade mig också till Alexanders mönsterspråk. Denna tidning är också skyldig en hel del till dem som läser den och försåg den med välbehövlig kritik, bland annat Bruce Anderson, Kent Beck, Bob Hinkle, Brian Foote, Pat McClaughry, Carl McConnell, Bill Opdyke, Don Roberts, Michael Seif, Dan Walkowski och recensenterna.
En del av det ursprungliga arbetet i ramverket REF diskuterade med hjälp av designmönster som ett sätt att beskriva ramverk.