Utvecklingen av komplexa system involverar alltid många intressenter som har olika perspektiv på det problem de tar itu med, systemet utvecklas och den process genom vilken det utvecklas. Ramverket ViewPoints utformades för att tillhandahålla en organisatorisk ram där dessa olika perspektiv och deras relationer uttryckligen kunde representeras och analyseras. Ramen erkänner att många inkonsekventa åsikter är oundvikliga, främjar en uppdelning av problemen och uppmuntrar decentraliserade specifikationer samtidigt som den ger stöd till integration genom förbindelser och sammansättning. I detta dokument reflekterar vi över ramen för ViewPoints, pågående arbete och framtida forskningsinriktningar. Alla större programutvecklingsinsatser kommer att involvera olika intressenter med olika aspekter av bekymmer eller perspektiv – som överlappar, kompletterar eller motsäger varandra. Dessa intressenter uttrycker sin oro med hjälp av en rad olika representationer och följer olika processer för att använda dessa representationer. Detta gör det särskilt svårt att fastställa förhållandet mellan olika perspektiv, men ändå avgörande för att kontrollera samstämmigheten och hantera inkonsekvensen mellan dessa perspektiv. Sådan multi-perspektiv mjukvaruutveckling har motiverat vår forskning i över ett decennium. Det förkroppsligar ett antal egenskaper som fortsätter att stå i centrum för organiseringen av mjukvaruutvecklingsverksamheten. Dessa egenskaper inkluderar behovet av att skilja mellan problem under programvaruutveckling, oundvikligheten av att ha flera inkonsekventa åsikter om processer och produkter för programvaruutveckling, och behovet av att resonera analytiskt över flera vyer för att förstå egenskaperna och konsekvenserna av en multi-perspektiv specifikation. Mycket av denna forskning har fokuserat på kravteknik (RE) aktiviteter inom programvaruteknikens livscykel. RE är prototypisk för multi-perspektiv mjukvaruutveckling. Flera berörda parter har olika syn på de problem som ska lösas, vilket i sin tur avgör de olika kraven i det system som ska utvecklas. Dessa krav är ofta inkonsekventa, men på ett godtagbart sätt, under någon del av RE-processen när kraven fortfarande framkallas, förhandlas och prioriteras. Detta dokument återspeglar kortfattat ramen ViewPoints [10, 33], som vi utvecklat för att organisera och hantera multi-perspektiv mjukvaruutveckling. I dokumentet granskas de grundläggande delarna i ramverket, deras existensberättigande och det sätt på vilket vi har använt dem under de senaste tio åren. Tidningen beskriver användningen av explicita relationer mellan ViewPoints för att hantera multiperspektiv mjukvaruutveckling, och rapporterar om vår senaste inkarnation av ViewPoints ramverk i form av xlinkit verktygslådan. I tidningen spekuleras sedan om behovet av mer meningsfulla relationer mellan flera ViewPoints för att resonera mer effektivt om strukturerade samlingar, eller konfigurationer, av sådana ViewPoints. ramen ViewPoints gav en infrastruktur för att fånga och organisera kunskap om programvaruutveckling. Vår uppfattning om en ViewPoint var ett objekt som inkapslade tvärgående och partiell kunskap om notation, process och diskurs, ur perspektivet av en viss intressent, eller grupp av intressenter, i utvecklingsprocessen. En systembeskrivning -en specifikation -därmed består en strukturerad samling löst kopplade, lokalt hanterade, distribuerade ViewPoints, med tydliga relationer mellan dem för att representera deras överlappningar. Dessa överlappningar är fokuspunkten för konsekvent kontroll mellan ViewPoints, och efterföljande inkonsekvenshantering, om ViewPoint-relationer inte skulle befinnas hålla. ViewPoints återberättar ett antal viktiga, väldokumenterade principer för programvaruteknik, och ytan ett antal nya. I grund och botten organiserar ViewPoints kunskap om programvaruutveckling baserad på separation av problem. En ViewPoint uttrycker oron hos en viss intressent, såsom en utvecklingsdeltagare eller en företrädare för ett område av oro som fångats upp av ViewPoint. Således kan en ViewPoint representera ett område av intresse inom ett projekt, en produkt eller en process, eller helt enkelt presentera en särskild 3URFHGLQJV RI WKH WK,QWHUQDWLRQDO &RQIHUHQFH RQ 6RIWZDUH (QJLQHULQJ,&6( ( ( perspektiv uttryckt i en särskild not). Valet av dimensioner av oro längs vilken att skapa ViewPoints kan vara resultatet av erfarenhet, karaktären av det aktuella problemet, eller helt enkelt organisatoriska behov. Nästa, men besläktade, nyckelprincip är att representationerna är heterogena. ViewPoints låter avsiktligt olika perspektiv representeras med hjälp av olika notationer, baserat på observationen att intressenter kommer att presentera sina perspektiv med hjälp av olika notationer, beroende på deras preferenser, behov eller omständigheter. Naturligtvis, att relatera olika perspektiv kommer oundvikligen att kräva ett visst uttryck för förhållandet mellan de olika notationerna, och ViewPoints utgör en ram för just ett sådant uttryck. Att använda ramen ViewPoints leder direkt till begreppet Distribuerbara ViewPoints -det vill säga ViewPoints som kan distribueras fysiskt eller logiskt. Den viktigaste principen som detta bygger på är decentralisering - tanken på att den kunskap som inkapslats inom varje ViewPoint framkallas lokalt, utvecklas lokalt och hanteras lokalt. En sådan decentralisering rör sig uttryckligen bort från alla begrepp om en monolitisk systemspecifikation som kan kontrolleras eller hanteras globalt, mot samlingar av löst kopplade partiella beskrivningar. Följden av heterogenitet, decentralisering och partiskhet är att relationer mellan ViewPoints är avgörande för att uppnå integration i dess många former. I ramen för ViewPoints är integration ofta metodisk, dvs. det handlar om meningsfull koppling av processer och notationer för att uppnå samordning och sammansättning, respektive [32]. Metoder kan därför konstrueras genom att man relaterar olika noteringar och förskriver när och hur de används. Dessutom kan metoder användas, vilket leder till många ViewPoints kopplade av momentiations av relationer som definieras under metodteknik. En annan konsekvens av en specifikation som består av många olika ViewPoints är de oundvikliga inkonsekvenser som uppstår mellan dessa ViewPoints. Den strategi som används av ramen ViewPoints är att leva med inkonsekvens för att fånga de olika perspektiven hos intressenterna. Överensstämmelse definieras genom inter-ViewPoint regler som uttrycker (statisk semantiska) relationer mellan ViewPoints [6, 34]. Inkonsekvent förvaltning är då processen för att hantera den potentiella uppsjö av regler och hantera ViewPoints när de önskade relationerna mellan dem inte håller [7, 12, 35, 37]. De principer som ViewPoints bygger på är fortfarande relevanta i samband med mjukvaruutveckling i dag. Den aspektsorienterade programvaruutvecklingsmiljön (AOSD) har under de senaste åren fokuserat på just den typ av "övergripande" frågor som undersökts inom ramen för ViewPoints. Denna gemenskap har främst fokuserat på frågor som rör programplaneringskoden, men det finns nu ett allt större erkännande av att dessa frågor också kan yttra sig i krav och utformningar, och därför kan det vara nödvändigt att beakta "tidiga aspekter" [4, 40]. Ramverket ViewPoints gav också en möjlighet till metodteknik – anpassning av metoder genom att blanda notationer [36], processer och riktlinjer för deras införande. Under sådan metodteknik kan olika typer ("mallar") av ViewPoints samlas ihop, och relaterade, vilket leder till flera heterogena ViewPoints när metoderna används (eller i ViewPoints terminologi, när ViewPoint-mallar är ögonblickliga). Även om metodteknik är en forskningsdisciplin, har den inte haft framgång, men den är i själva verket allmänt tillämpad. Det enhetliga modellspråket (UML) med dess mångskiftande, heterogena modelleringsuppgifter, användardefinierade profiler, utvidgningsmekanismer och olika processer där det används kan ses som ett exempel på hur man går till väga för att välja den lämpligaste metoden för det aktuella problemet [1]. Att uttrycka och kontrollera förhållandet mellan de olika modellerna är fortfarande en utmaning. Decentraliseringen stod i centrum för ramen för ViewPoints. Många av de identifierade problemen är av direkt betydelse för tillhandahållandet av verktygsstöd till distribuerade programvarutekniker som arbetar samarbetsvilligt och asynkront [21, 30]. Konsekvenserna av att stödja flera olika åsikter, nämligen behovet av att leva med och hantera inkonsekvensen mellan dessa åsikter, är av särskilt intresse [3, 9, 15, 16]. Den programvarutekniska gemenskapen i allmänhet, och RE-gemenskapen i synnerhet, verkar ha accepterat behovet av att artikulera och hantera flera vyer i programvaruutvecklingsprocessen. Det finns en rad olika problem där dessa åsikter kan skiljas åt, inklusive aspekter, aktörer, representationssystem eller processer. Att dela upp stora monolitiska specifikationer i många mindre partiella specifikationer är ett sätt att hantera sådana specifikationer. Ramverket ViewPoints formulerade en forskningsagenda där ovanstående idéer presenterades. Den presenterade också, genom fallstudier och stöd för demonstratorverktyg, en vision av multi-perspektiv mjukvaruutveckling där metoder kan konstrueras, många partiella, inkonsekventa specifikationer skapas, och konsekvens samband mellan dem kontrolleras. Forskningsagendan förändrades över tid och ihärdig läsning av våra artiklar kommer att avslöja olika och, ironiskt nog, inte helt konsekventa varianter av ramverket. Det som våra tidiga demonstranter inte uppnådde var verkligt heterogena framställningar. Det är också rättvist att anklaga vårt tidiga arbete för att tillhandahålla en referensmodell utan ett rimligt distribuerat genomförande för att stödja det. Distributionen har till stor del behandlats i vår senare 3URFHHGLQJV RI WKH WK,QWHUQDWLRQDO &RQIHUHQFH RQ 6RIWZDUH (QJLQHULQJ,&6( ¶,(( arbete på xlinkit, en verktygslåda för att kontrollera dokument som distribueras på webben, beskrivs i nästa avsnitt. Heterogeniteten har gett upphov till något fler problem. The ViewPoints ramverk gjorde stora polemiska spel av heterogenitet. Den samordnade användningen av flera modelleringsbeteckningar är nu vanlig och allmänt accepterad som rätt metod för specifikation. Det är inte alls klart att vårt främjande av heterogenitet när det gäller att representera kartläggningar mellan modellering av representationer och konsekventa relationer mellan modeller med hjälp av flera dessa anmärkningar var rätt tillvägagångssätt. Visst, vårt senare arbete [6, 12, 18, 27] har antagit en enda meta-språk för att uttrycka förhållandet mellan flera åsikter (som UML gör i antagandet av en enda meta-modell och ramar av begränsningar). Det enda språket är avgörande för att utföra meningsfulla analytiska resonemang. I en stor del av vårt arbete har vi anammat predikativ logik som en underliggande representation på vilken man kan utföra resonemang [12]. I vissa fall ansåg vi att det var nödvändigt att anpassa den klassiska logiken för att kunna resonera i brist på inkonsekvens [18]. I andra fall använde vi särskilda former av klassisk logik för att resonera om de ändrade specifikationerna [14, 41]. Senast, i samband med xlinkit, har vi baserat våra tekniker för att reparera inkonsekvenser mellan specifikationer på grund av första ordningens logik med några betydande praktiska framgång [29]. xlinkit är en direkt efterföljare till en stor del av arbetet med ViewPoints. Det ger en partiell insikt och en demonstration om att många av de centrala idéerna i ramverket var sunda. Det har också, som det är dags att genomföra, kommit fram till ett brett spektrum av nya frågor, som vi hade ägnat föga uppmärksamhet i vårt tidigare arbete. xlinkit, en lätt applikationstjänst som tillhandahåller regelbaserad länkgenerering och kontrollerar överensstämmelsen hos distribuerat webbinnehåll. En fullständig beskrivning finns i [27, 28, 29] och online-demonstrationer, handledningar och annat material finns på http://www.xlinkit.com. Användningen av xlinkit är ganska enkel. Det ges en uppsättning distribuerade XML-resurser och en uppsättning potentiellt distribuerade regler som relaterar till innehållet i dessa resurser. Reglerna ger uttryck för konsekventa begränsningar för olika typer av resurser. xlinkit returnerar en uppsättning XLinks, i form av en länkbas, som stöder navigering mellan element av XML-resurser. Här används XML som det gemensamma utväxlingsspråket för att övervinna heterogenitet. Xlinkit regelspråk är första ordningens logik (den konkreta syntaxen är XML). Xlinkit 'kontrollmotor' ger en ny länkning semantik till detta språk som returnerar hyperlänkar mellan inkonsekventa element istället för booleska värden. Hyperlänkarna ger mycket exakta diagnostiker som vi anser är nödvändiga för inkonsekvenshantering. xlinkit har ett rapporteringsramverk "Pulitzer" som använder dessa diagnostik för att ge informativ rapportering till resurs, aka synvinkel, ägare. Den senaste tidens arbete, som rapporterades vid denna konferens, har koncentrerats till "reparationer". Med hjälp av reglerna, genom statisk analys, kan vi identifiera en uppsättning reparationer som kan användas för att återställa överensstämmelse. Dessa reparationer, eller i varje fall en förnuftig del av dem, som bestäms av en lämplig myndighet, kan användas i samband med vår diagnostiska rapportering för att stödja inkonsekvenshantering. xlinkit utnyttjar Internets standardteknik. Det stöder storskalig dokumentdistribution och kan stödja flera utplaceringsmodeller. Den har en stark formell grund. Vi har genomfört ett antal storskaliga utvärderingar, inklusive en studie som kontrollerar UML-modeller, Java-kod, EjB-utplaceringsinformation och UML-profilinformation. Denna och liknande studier ger oss förtroende för xlinkit och visar att vi har gått en bit på vägen mot att göra ViewPoints till en verklighet. Xlinkit kommersialiseras nu av Systemwire, ett forskningsspinoutföretag. Erfarenheten av xlinkit har fått oss att inse utmaningarna i fråga om skalbarhet, i fråga om dokumentens storlek, antalet regler och komplexiteten i dessa regler. Vi har implementerat en inkrementell kontroll, en distribuerad kontroll, smart caching med hjälp av ett XML-arkiv och en ultra-hög prestanda replikerad kontroll. Vi har också ägnat en stor ansträngning åt optimering för att se till att kontroll och omkontroll kan göras på stora dokumentsamlingar vid behov. Det har också tagit lång tid att säkerställa användbarhet, goda gränssnitt och meningsfulla felmeddelanden. Dessa är inte perifera frågor, de har varit väsentliga för att kunna slutföra fallstudierna, och locka de externa användare, som validerar vårt arbete. Det finns en betydande framtida forskningsagenda för xlinkit. En av de viktigaste punkterna på denna agenda är förhållandet mellan kontroll och arbetsflöde. I ramen för ViewPoints angavs att kontroller skulle utlösas av en processmodell. Denna processmodell skulle identifiera vilka kontroller som bör tillämpas när och resultaten av kontrollerna sedan skulle kunna användas för att driva processen. Denna idé togs först upp i vårt arbete med Tool Assisted Requirements Analysis [TARA paper] och utforskades ytterligare i samband med Viewpoints [21]. Vårt arbete med att följa standarderna är i stort sett detsamma [8]. Cass & Osterweil [2] har tittat på att göra processcentrerad kontroll i samband med xlinkit med Little-JIL som processspråk. Vi är angelägna om att göra något liknande, förmodligen med hjälp av en enkel reaktiv strategi som drar nytta av distribuerad händelseövervakning. 3URFHHGLQJV RI WKH WK,QWHUQDWLRQDO &RQIHUHQFH RQ 6RIWZDUH (QJLQHULQJ,&6( ¶,((( Vi har ägnat oss åt att tillhandahålla en ram för separation av farhågor och har gjort några måttligt framgångsrika attacker på de tillhörande integritetsproblem som följer av detta. Vi inser dock att detta bara är en del av historien, "har vi söndrats för att segra måste vi återförenas för att härska" [19]. Programvaruutveckling kräver att vi kan utföra ett rikt resonemang och analys över flera vyer. Även om verktyg som xlinkit hjälper till att upprätta länkar och kontrollera regler, är det fortfarande långt ifrån det resonemang och den analys som vi planerar bör stödjas. Hur kan vi göra ytterligare framsteg i detta avseende? Ett exempel på var denna utmaning är uppenbar är förhållandet mellan krav och programvaruarkitekturer, ett hett ämne inom aktuell programvaruteknisk forskning. I modellen "twin peaks" [17, 39] beskrev vi vår syn på den gemensamma utvecklingen av krav och arkitekturer. Vi vill naturligtvis skilja på uttrycken för kraven och representationen av programvaruarkitekturen. Å andra sidan vet vi att många så kallade icke-funktionella krav driver identifieringen av en lämplig arkitektur och, vice versa, att arkitektonisk analys informerar krav. Att hantera dessa relationer kräver mer än en konsekvent kontroll, även om det är viktigt. Vi måste kunna resonera om egenskaperna hos de system som vi förväntar oss att bygga utifrån en integration eller sammansättning av olika ViewPoint-specifikationer. Vi bör också kunna identifiera ofullständighet och utföra avvägningsanalyser mellan alternativa utvecklingsbeslut. Med tanke på vår erfarenhet och vårt intresse för programvaruarkitekturer har vi också undersökt stöd för resonemang över hela synfältet genom att utnyttja den gemensamma underliggande strukturen i den föreslagna programvaruarkitekturen. I synnerhet används arkitekturen som skelettramverk för att hänga intresseaspekterna [20, 24]. I motsats till konceptet med en enda informationskälla som stöder flera olika åsikter, innebär detta tillvägagångssätt att den gemensamma underliggande strukturen eller arkitekturen kan utarbetas med beteende, prestanda, genomförande eller annan information. Hittills har detta arbete varit löst baserat på Darwin Software Architecture language [22] och LTSA (Labelled Transition Systems Analyser) [23] för beteendeanalys och animation [25], och utvidgas till att omfatta syntes från scenarier [44] och prestandaanalys. Men även här är relationerna begränsade till den granularitet som stöds av de komponenter och interaktioner som är inneboende i arkitekturen snarare än till några djupare föreställningar som kan vara på en finare granularitet eller ortogonal till arkitekturen. Det är tydligt att vi fortfarande saknar medel för att uttrycka mer olikartade relationer för att resonera mer effektivt om strukturerade samlingar, eller konfigurationer, av ViewPoints. Ett klassiskt exempel är den typ av resonemang som behövs för att motverka användbarhet mot säkerhet. Förhållandet mellan två sådana systemkrav kompliceras av variationen eller bristen på precision i deras uttryck. Därför, för att uttrycka relationer mellan dem, individuell säkerhet och användbarhet ViewPoints måste bättre förstås och ledas. Slutligen, återgår vi till vårt exempel av relaterade krav och arkitekturer, vi undersöker för närvarande sätt att beskriva de mångfacetterade relationer som oundvikligen uppstår mellan problem och lösningsstrukturer i mjukvaruutveckling. Vi använder Jacksons problemramar för att kartlägga delade fenomen mellan krav, problemdomäner och den (programvara) maskin som ska utvecklas [17]. Därför är våra problemramar inte bara överbrygga klyftorna mellan problem och lösningar, de är också en uttrycklig representation av några ganska komplexa relationer mellan olika beskrivningar i programvaruutvecklingsutrymmet. Vi har börjat utforska denna typ av tillvägagångssätt för att bättre specificera och analysera säkerhetskraven och för att relatera dem till säkerhetshot [5]. ramen ViewPoints ger ett generiskt sätt att uttrycka sambanden mellan beskrivningar i detta sammanhang. Men vår erfarenhet hittills visar att det är svårt att identifiera, uttrycka och resonera om mer meningsfulla relationer! Medgivanden
Viewpoint-orienterad mjukvaruutveckling är välkänd i litteraturen [GEMT00, GMT99, EEHT97], men identifiera, uttrycka, och resonemang om meningsfulla relationer mellan visa modeller är hårt REF.
ViewPoints: meaningful relationships are difficult!
{'venue': '25th International Conference on Software Engineering, 2003. Proceedings.', 'journal': '25th International Conference on Software Engineering, 2003. Proceedings.', 'mag_field_of_study': ['Computer Science']}