Abstract During object-oriented system development, programming should be preceded by analysis and design to assure that the system fulfils the demands of the customer and simplify during the development phase and documentation. When modeling the analysis and design phases, several different notations may be used. One of these is the UML (Unified Modeling Language) which this thesis will cover. The aim is to compare the use of the UML i practice versus what is said in the literature. The investigation is built upon interviews at different companies to receive their reflections about the UML. Questions at issue are why and when the selected companies use the UML and what diagrams they use. We also investigate whether they strictly follow the UML notation or complement it with another kind of notation. Moreover two companies not using the UML was interviewed to find out why they have chosen not to. The thesis starts with an introduction to object-oriented system development with analysis and design followed by the history of the UML and its most common diagrams according to Larman [1]. These diagrams are use case, conceptual model, system-sequence diagram, contract, interaction diagram, class diagram and state diagram. Each diagram is explained with text and graphics. The most important results are that the UML is considered being adequate to the system developers. They use a number of the most common diagrams. Furthermore the CASE-tools showed not to meet the demands of the developers. We believe that inadequate tools hinders the future diffusion of the UML on the market. Improved tools for modeling and documentation are desired for all of the interviewed companies.

Recommender system blir allt vanligare och att kombinera recommender system med användningen av design patterns kan vara ett steg i rätt riktning för att komma närmre tekniker och program som skulle kunna öka kvaliteten hos programvaran i programvaruutveckling genom att öka utbyggbarheten och underhållbarheten hos programvaran. Syftet med arbetet i den här rapporten är att utvärdera ett design pattern recommender program. Programmet kommer att utvärderas med hjälp av intervjuer av utvecklare och fallstudier hos tre företag. Frågorna i intervjun kommer att bygga på kriterier som används för utvärdering av CASE verktyg.

<p>Denna rapport behandlar framtagandet av ett utvärderingsramverk för designtransformationer. I en utvecklingsprocess används olika typer av designtransformationer och ett problem är att det idag inte finns en koncensus om vilka aspekter hos dessa transfomationer som ska bedömas vid en utvärdering.</p><p>I rapporten presenteras ett utväderingsramverk som innehåller en samling faktorer viktiga att beakta vid en utvärdering av designtransformationer. Ramverket har utvecklats med en nyligen presenterad metod för utveckling av utvärderingsramverk.</p><p>Metoden är ursprungligen framtagen för ett delvis annorlunda problemområde, så rapporten presenterar en undersökning av metodens lämplighet på det delvis nya problemområdet. Författaren finner att inga långtgående slutsater kan dras om metodens lämplighet, eftersom metoden inte tillämpats fullt ut. Problem under den senare fasen av metodtillämpningen gjorde att vissa, för metoden väsentliga delar, inte kunde genomföras.</p><p>Däremot presenteras i rapporten ett utvärderingsramverk för designransformationer, och ramverket är en syntes av litteratur skiven om designtransformationer.</p>

<p>Alltid har mjukvaruföretagen varit intresserade av att bedriva applikationsutvecklingen så effektiv och lönsam som möjligt. För detta avseende använder många utav dem olika CASE-verktyg. Ett sådant CASE-verktyg är VISIO 2000 Enterprise. CASE-verktyg kan t ex användas för att genomföra transformeringar mellan modeller och koder. Denna möjlighet underlättar applikationsutvecklingen, men tyvär kan sådana transformeringar medföra eventuella förluster av data och leda till att eventuella semantiska förluster uppstår. Dessa förluster kan innebära att den representerade informationen i modeller och koder inte är det samma efter en transformation. Därför är det intressant att undersöka hur bra ett CASE-verktyg klarar av detta innan det kan avändas som stöd vid applikationsutveckling. I denna rapport undersöks genereringsmöjligheterna i CASE-verktyget VISIO 2000 Enterprise samt de eventuella semantiska förluster som kan uppstå vid transformationer mellan modeller och koder via CASE-verktyget. Olika tester innehållande transformationer mellan modeller och koder som representerar grundläggande relationer mellan olika klasser har genomförts för att undersöka förluster av relationer mellan klasser samt förluster av relationsnamn, medlemsfunktioner och medlemsvariabler i klasserna och koden. Utifrån testresultaten kan slutsats dras att VISIO kan vara bra använda vid applikationsutveckling när det gäller transformationer av modell till kod men inte tvärtom.</p>

Denna rapport behandlar framtagandet av ett utvärderingsramverk för designtransformationer. I en utvecklingsprocess används olika typer av designtransformationer och ett problem är att det idag inte finns en koncensus om vilka aspekter hos dessa transfomationer som ska bedömas vid en utvärdering. I rapporten presenteras ett utväderingsramverk som innehåller en samling faktorer viktiga att beakta vid en utvärdering av designtransformationer. Ramverket har utvecklats med en nyligen presenterad metod för utveckling av utvärderingsramverk. Metoden är ursprungligen framtagen för ett delvis annorlunda problemområde, så rapporten presenterar en undersökning av metodens lämplighet på det delvis nya problemområdet. Författaren finner att inga långtgående slutsater kan dras om metodens lämplighet, eftersom metoden inte tillämpats fullt ut. Problem under den senare fasen av metodtillämpningen gjorde att vissa, för metoden väsentliga delar, inte kunde genomföras. Däremot presenteras i rapporten ett utvärderingsramverk för designransformationer, och ramverket är en syntes av litteratur skiven om designtransformationer.

Alltid har mjukvaruföretagen varit intresserade av att bedriva applikationsutvecklingen så effektiv och lönsam som möjligt. För detta avseende använder många utav dem olika CASE-verktyg. Ett sådant CASE-verktyg är VISIO 2000 Enterprise. CASE-verktyg kan t ex användas för att genomföra transformeringar mellan modeller och koder. Denna möjlighet underlättar applikationsutvecklingen, men tyvär kan sådana transformeringar medföra eventuella förluster av data och leda till att eventuella semantiska förluster uppstår. Dessa förluster kan innebära att den representerade informationen i modeller och koder inte är det samma efter en transformation. Därför är det intressant att undersöka hur bra ett CASE-verktyg klarar av detta innan det kan avändas som stöd vid applikationsutveckling. I denna rapport undersöks genereringsmöjligheterna i CASE-verktyget VISIO 2000 Enterprise samt de eventuella semantiska förluster som kan uppstå vid transformationer mellan modeller och koder via CASE-verktyget. Olika tester innehållande transformationer mellan modeller och koder som representerar grundläggande relationer mellan olika klasser har genomförts för att undersöka förluster av relationer mellan klasser samt förluster av relationsnamn, medlemsfunktioner och medlemsvariabler i klasserna och koden. Utifrån testresultaten kan slutsats dras att VISIO kan vara bra använda vid applikationsutveckling när det gäller transformationer av modell till kod men inte tvärtom.

CASE är en förkortning för Computer Aided Software Engineering. Syftet med CASE-verktyg är att öka produktiviteten för dem som utvecklar mjukvarusystem genom att datorisera processer i deras arbete. Det finns dock problem med CASE-verktyg. Tidigare forskning pekar på att dessa ofta är komplexa i sitt utförande, att de lätt ifrågasätts om de visar sig ha buggar och att inlärnings-tröskeln är ofta hög till följd av den höga komplexiteten. Man frågar sig också hur komponenter ska vara utformade i verktygen för att fler ska använda dem. Vidare saknas nyare undersökningar med fokusering på användbarhet för CASE-verktyg och framförallt där man utgår från användaren. Vad gäller CASE-verktyg har det skett en del begreppsbyten inom området. Ett ganska vanligt begrepp idag är IDE. Det som är inbegripet i IDE utgörs till stor del av det som räknas till CASE i de äldre texterna. I den här studien har vi valt att använda begreppet CASE-verktyg för att få en tydlig koppling till de äldre studierna. Studien avser att klargöra vilka fördelar och brister utvecklare upplever beträffande användbarhet i CASE-verktyg. Målet med studien är att bidra till en större förståelse för vad CASE-verktyg är och i synnerhet hur de bör vara utformade för att ge ett bra stöd till användaren. Då CASE-verktyg och användbarhet är begrepp med många olika definitioner kommer de teoretiska grunderna diskuteras. Den användbarhet som undersöks baseras på kriterier som kan användas för att avgöra vad som får utvecklarna att ta verktyget i bruk. I studien har vi utarbetat en anpassad definition för CASE-verktyg genom att slagit ihop två definitioner. Vidare har vi visat att det specifika verktyget Visual Studio som undersöks i studien kan klassas som ett CASE-verktyg genom att jämföra verktyget med vår valda definition för CASE-verktyg. I teoriavsnittet har vi beskrivit systemutvecklingsprocessen och systemutvecklingsmodeller för att förstå täckningsgraden hos CASE-verktyg och ge en grundläggande kunskap för att förstå den miljö som dessa används i. Två matriser med faktorer för Visual Studio och kriterier för användbarhet har använts som hjälpmedel för att kategorisera och analysera data under studiens analys. Studien åskådliggör vilket förbättringspotential ett CASE-verktyg som Visual Studio har och lyfter fram konkreta förslag på hur CASE-verktyg bör utformas för att tillgodose användares krav på användbarhet. Resultatet visar bland annat; att supporten som verktyget erbjuder bör vara stabil och stödja användarnas behov, att CASE-verktyg bör vara intuitiva och enkla att lära sig samt att dokumentationskopplingen till kompileringsfel bör vara bättre. Vidare visar resultatet att den främsta fördelen är stödet för support som ges av dessa verktyg och den främsta bristen är att versionshanteringen är svag.