Kognitiv vetenskap betonar styrkan i visuella formalismer för mänskligt lärande och problemlösning. Inom programvaruteknik kan en tydlig, visuell presentation av ett systems arkitektur avsevärt minska ansträngningen att förstå. Men alltför ofta saknar dokumentationen av komplexa programvarusystem en tydlig identifiering av de arkitektoniska beståndsdelarna och har inte tillräckligt med koppling till källkoden. Det är vår uppfattning att visualisering av de arkitektoniska beståndsdelarna i källkodsmodellen är ett oumbärligt hjälpmedel för den vägledda utvecklingen av storskaliga mjukvarusystem. I detta dokument presenterar vi ett prototypverktyg för att visualisera både publicerade, generiska designmönster samt väl genomtänkta, ad-hoc designlösningar, med tanke på den omvända-konstruerade källkoden för vissa system. Vi diskuterar arkitekturen och kärnan funktionaliteten i detta verktyg, adresserar källkod omvänd konstruktion, design arkiv, design representation, och design kluster. Därefter presenterar vi våra visualiseringsmål och detaljerar våra tekniker för mönstervisualisering. Ett exempel på fallstudie hjälper oss att explicera och illustrera vårt arbete. Nyckelord: Designvisualisering, programvaruförståelse, designmönster, designkomponent, programvaruarkitektur, objektorienterad design, verktygsstöd. Programvaruförståelse är starkt relaterad till förmågan att resonera om ett systems arkitektur [14]. Kunskap om miljön och den kultur i vilken ett system byggdes och inbäddades är en förutsättning för arkitektoniskt resonemang. Inom anläggningsbranschen kräver till exempel en djup förståelse av byggnadernas och städernas utformning att man i förväg förstår invånarnas geografi, kultur och levnadsförhållanden [1]. Detta exempel kan mycket väl anpassas för att passa många andra tekniska discipliner inklusive programvaruteknik; men det finns en subtil skillnad mellan klassisk ingenjörskonst och programvaruteknik. Medan i klassisk ingenjörskonst arkitektoniska stilar ofta kan förstås bara genom att titta på utåt synliga form och beteende i ett system, programvaruteknik saknar sådan kartläggning mellan yttre utseende och inre struktur. Inom programvaruteknik, allt för ofta, bygger resonemanget om arkitekturen i ett system på systemets input/output beteende, vilket leder till fel underhållsbeslut, som slutligen bryter den konceptuella integriteten [5] av den arkitektoniska designen. För att göra det möjligt för utvecklarna att fatta mer välgrundade beslut arbetar vi på en process och ett verktyg som kan bevara historien om både den ursprungliga designen och den efterföljande utvecklingen av programvara. Vi anser att kunskap om kulturen och utvecklingsprocessen är en förutsättning för en styrd utveckling av programvara. Att dokumentera design och ändra beslut på ett systems utvecklingsväg, och hur dessa beslut relaterar till dess grundläggande beståndsdelar (såsom klasser, attribut, metoder och relationer), är ett oumbärligt stöd för att förstå de subtila kompromisser som ingår i programvarusystem. Det är vår uppfattning att för en effektiv systemförståelse måste sådan dokumentation göras med hjälp av lämpliga visualiseringsmetoder. Vi håller med Harel om att "framgångsrik systemutveckling i framtiden kommer att kretsa kring visuella representationer" [11]. Vår inställning till en mer principiell process av programvarukonstruktion [15, 16] bygger på mönster, såsom arkitektoniska mönster, designmönster, idiomer och protomönster ("mönster i väntan som ännu inte är kända för att återkomma" [2] en kompositionsutvecklingsprocess där programvara konstrueras genom specialisering, anpassning, montering och förändring av mer grundläggande designkomponenter. Ett viktigt bidrag till detta tillvägagångssätt är att det ger kompletta mönster (det vill säga inte bara deras struktur, utan lika viktigt, deras avsikt, tillämplighet, motivation och alla andra mer informella komponenter) som konkreta programvarudesign artefakter. Ytterligare ett bidrag är att sådana konstruktionskomponenter kan tjäna som grund för en process för utveckling av kompositionsprogramvara, där grundläggande konstruktionskomponenter monteras på sammansatta komponenter, som i sin tur kan fungera som grundläggande komponenter för en mer komplett eller mer komplex design. Slutligen är ett tredje bidrag att utvecklingen av konstruktionskomponenter kan spåras, vilket gör det möjligt att se tillbaka på ett systems historia och dess arkitektoniska utveckling. För ytterligare detaljer om detta tillvägagångssätt, se [15, 16]. I detta dokument fokuserar vi på visualisering av mönsterbaserad programvarudesign och dess logik, och diskuterar ett prototypverktyg som vi har utvecklat för detta ändamål. Som en motivering utgör avsnitt 2 i dokumentet ett exempel på fallstudier. Avsnitt 3 beskriver kärnfunktionaliteten och arkitekturen i vårt verktyg. Specifikt omfattas fyra aspekter: källkod omvänd konstruktion, design arkiv, design representation och konstruktion kluster. Sedan, avsnitt 4 detaljer visualisering aspekten av design mönster konstruktion. Avsnitt 5 behandlar relaterat arbete och slutligen avsnitt 6 innehåller en sammanfattning och en diskussion om det pågående arbetet. Gamma och al. [9] motivera sin designmönsterkatalog med en fallstudie där de tillämpar några av sina designmönster på Lexi, en förenklad version av Doc redaktör [6]. Lexi möjliggör redigering av dokument som innehåller text, grafik, diagram och liknande, stöder flera formateringsalgoritmer för textlayout och uppvisar ett grafiskt användargränssnitt. Gamma och al. beskriva sju designproblem när man bygger en sådan dokumentredigerare och använda åtta mönster för sin lösning (tabell 1). I detta dokument använder vi Lexi som en fallstudie, eftersom det har en begränsad räckvidd, men ändå är tillräckligt komplex för att kommunicera alla viktiga frågor i vår design visualiseringsstrategi. Figur 1 visar Lexi som ett kluster av inbördes relaterade klasser och klasshierarkier. Om man ser på Lexi ur detta perspektiv, kan man mycket väl förstå dess klassstruktur, men ändå, det kommer att krävas även en professionell designer en hel del ansträngningar för att till fullo förstå det ansvar som ingår i Lexi design, och för att förstå hur dessa ansvarsområden är utspridda över de olika klasserna. I huvudsak förmedlar figur 1 inte de designproblem och lösningar som går utöver klasser och klasshierarkier. Figur 2, I kontrast, visar samma klass diagram, men överlagd med ytterligare designinformation. Det illustrerar de komplexa mekanismer som håller ihop Lexi, och visar de klasser där dessa mekanismer samarbetar för att utföra systemets ansvar. I Lexi är dessa mekanismer baserade på välkända, väl beprövade mönster, vilket ytterligare ökar uttrycket i diagrammet. Design mönster är de fordon som förmedlar till läsaren av diagrammet inte bara struktur, beteende och dynamik design, men lika viktigt, 1 Verktyget använder färgade konturer runt klasser för att skilja mellan mönster; för denna svart/vit presentation valde vi att använda omslutande polygoner istället. konstruktionsmotivering och de kompromisser som gjordes när man valde en viss form av genomförande [9]. Information om den konceptuella arkitekturen är nödvändig för den guidade utvecklingen av programvara, men knappast tillgänglig och oprecis kommunicerad till utvecklaren i traditionella programvaruutvecklingsmiljöer. Denna brist på information gör det svårt att fastställa vilka klasser som är lämpligast för att införliva ansvaret för nya eller ändrade systemkrav. Med mönsterbaserad visualisering strävar vi efter att öka informationsinnehållet i diagram och ge mer insikt i programvarans konceptuella arkitektur. Ovanstående exempel bör vara tillräckligt motiverande för att föreställa sig tekniker och verktyg som organiserar programvara runt mönster, visualisera dem och möjliggöra zoomning in och ut ur både formella och informella mönsterkomponenter. I detta avsnitt diskuterar vi kärnfunktionaliteten och arkitekturen hos det prototypverktyg vi har utvecklat för att stödja dessa aktiviteter. Syftet med detta verktyg är att hjälpa till att förstå programvara genom sin organisation runt mönster. Verktyget tar upp fyra huvudfrågor: källkod omvänd konstruktion, design arkiv, design representation, och design kluster (se figur 3 ).  Syftet med källkod omvänd konstruktion är att extrahera en modell från källkod. Vid denna tidpunkt stöder vi endast C++. Med hjälp av C++ källkodsanalyssystemet GEN++ [7] genererar vårt verktyg en intermediär AS-CII-baserad representation av relevanta källkodselement: klasser, attribut, metoder, generaliseringsrelationer, associationsrelationer och ögonblicksrelationer. Ett importverktyg tolkar denna mellanliggande representation och lagrar källmodellen i ett centralt arkiv, kallat designarkiv. Vår avsikt med detta ASCII-baserade mellanformat var att göra verktyget oberoende av något specifikt programmeringsspråk. I en kommande version kommer vi att stödja CDIF (CASE Data Interchange Format) som mellanliggande representation, för bättre kompatibilitet med kommersiella CASE miljöer. Syftet med designarkivet är att tillhandahålla centraliserad lagring, manipulation och förfrågan av källmodellen, de abstrakta designmönstren ("off-the-shelf"-designmönstren som finns i litteraturen och beskrivs i mallformat [9] ), och de implementerade designmönstren inom källmodellen. Schemat för designarkivet är baserat på UML-metamodellen 1.1 [22]. För närvarande fungerar det objektorienterade databashanteringssystemet Poet50 [19] som gränssnitt. Schemat representeras som en Java 1.1 klasshierarki; klasserna inom denna hierarki utgör modellerna för MVC-baserade grafiska redaktörer av verktyget. Med hjälp av förkompilatorn av Poet50:s Java Tight Bindning kan en objektorienterad databas genereras från denna klasshierarki. Syftet med designrepresentation är att tillhandahålla interaktiv visualisering och förfining av källkodsmodeller, abstrakta designmönster och implementerade mönster. Denna komponent implementeras baserat på Java 1.1 och det grafiska redigeringsprogrammet jKit/GO [13]. I det nuvarande utvecklingsstadiet har vi implementerat klassdiagram baserade på UML notation 1.1 [22]. De informella beståndsdelarna i designmönster beskrivs med HTML. För att visualisera HTML-koden används ICEBrowser-verktyget [12], en JavaBeans-komponent.
Schauer & Keller REF utvecklade ett verktyg för att dokumentera programvarusystem.
Pattern visualization for software comprehension
{'venue': "Proceedings. 6th International Workshop on Program Comprehension. IWPC'98 (Cat. No.98TB100242)", 'journal': "Proceedings. 6th International Workshop on Program Comprehension. IWPC'98 (Cat. No.98TB100242)", 'mag_field_of_study': ['Computer Science']}