Då man arbetar objektorienterat inom systemutvecklingen sägs det att återanvändning är en av fördelarna med detta arbetssätt. Mitt syfte i denna uppsats var att undersöka hur systemutvecklingsföretag som arbetar objektorienterat ser på fenomenet objektorientering och återanvändning. Studien skall även ge svar på hur de arbetar med återanvändning och vad de återanvänder, eller vad som ligger bakom då de inte arbetar mer för återanvändning. För att besvara mina frågeställningar har jag intervjuat sju informanter på sju olika företag. Jag har haft ett hermeneutiskt förhållningssätt i min studie, vid intervjuerna har jag använt mig av en kvalitativ ansats och vid analysen har jag använt mig analytisk induktion. Resultaten i min studie visar att objektorientering banar väg för återanvändning och ger effektivare systemutveckling. Resultaten visar också att då hjulet inte behöver uppfinnas på nytt, så leder det till tidsbesparingar och lägre kostnader för företagen. Alla företag arbetar med återanvändning, antingen mer eller mindre, men för att arbeta mer med det behövs en organisation som tar hand om det merarbete som tillkommer vid återanvändning. Slutsatser i denna studie är att objektorientering ger enklare system till skillnad från de traditionella systemutvecklingsmetoderna, det ger även säkrare system och snabbare systemutveckling, vilket även återanvändning leder till. För att bedriva återanvändning i större skala behövs det en organisation inom företaget som driver detta. / When you work object-oriented in system-development it is said that reuse is one of the benefits with this way of working. My purpose in this study was to examine how system development-companies, which work object-oriented, look at the object-orientation and reuse- phenomena. With this study I also want answers that say if they work with reuse and if they do what they reuse. To answer my questions at issue I have interviewed seven informants from seven different companies. I have had a hermeneutical attitude in my study, I have used a qualitative projection and in the analysis I have used an analytic induction. The results in my study shows that object-orientation pave the way for reuse and give more effective system-development. The results also show that if the wheel doesn’t have to be invented again, over and over, it leads to timesaving and lower costs for the companies. All companies work with reuse, more or less, but to be able to work even more with the reuse-issue the company needs an organization witch is able to take care of the extra work witch arise with reuse. The conclusion of this study is that object-orientation gives easier system in contrast to the traditional method of system-developments, it also gives more secure system and faster system-developing, witch also reuse leads to. There is a need for an organization within the company that is able to drive the reuse- issue, if they are going to be able to reuse in larger scale.

In the end of the 80´s the area of system development moved into a new era. As a consequence many new methods and development models emerged which in many cases resulted in problems when choosing system development models and methods. As a result of these problems the today standardized modeling language UML (Unified Modeling Language) was created. UML is tailored to support many different types of projects. This is possible because of UML’s capacity to be adjusted and adapted to a specific company environment. The purpose of this bachelor thesis is to investigate how and why companies use UML and what experiences and opinions those who use UML have of using UML in practice. To fulfill our purpose we have chosen to carry out a qualitative study with semistandardized interviews. The interviews were accomplished on four companies in Jönköping. The result of the research shows that the primary reason for companies to carry out modeling is because it results in good documentation which makes development, administration and operation easier. Furthermore, the study has shown that the reason that companies have chosen UML is because it is a standard which is suited for various different projects and also for the development model used in the company. The standardization is also, according to all companies, the primary strength with UML. Weaknesses in UML are considered to be the lack of process diagrams and standardized syntax in modeling tools. There was found to be an increase in the number of diagrams used the longer the companies have used UML. The diagrams applied by all companies are: use case diagram, class diagram and sequence diagram. Moreover, the use of diagrams for a specific project is dependent on the project type and size. However, none of the companies utilize the flexibility to adjust the syntax. All companies combine UML with RUP or business customized development models with characteristics from RUP. There is, however, a difference in how companies use the diagrams in combination with the development models. This probably depends on the companies’ iterative way of working where the diagrams are involved in the whole system development process. / I slutet av 80-talet gick systemutvecklingen in i ett nytt skede. Detta fick som följd att många nya metoder och utvecklingsmodeller för systemutveckling skapades vilket i flera fall ledde till problem vid val av systemutvecklingsmetod och modell. Till följd av detta skapades det idag standardiserade modelleringsspråket UML (Unified Modeling Language). UML är anpassat för att stödja många olika typer av projekt eftersom det tillåter företagsspecifika anpassningar och förändringar. Syftet med studien är att undersöka hur och varför företag använder sig av UML samt vilka erfarenheter och uppfattningar de som arbetar med UML har av att tillämpa det i praktiken. För att uppfylla syftet har vi valt att genomföra en kvalitativ studie med semistandardiserade intervjuer. Intervjuerna utfördes på fyra företag i Jönköpingsregionen. Resultatet av studien visar att den främsta anledningen till att företag modellerar är att det ger en bra dokumentation vilket underlättar utveckling, förvaltning och drift. Vidare har studien visat att UML har valts på grund av att det är en standard som lämpar sig för många olika projekt samt för att UML passar den utvecklingsmodell som tillämpas på företaget. Standardiseringen är även enligt samtliga företag den främsta styrkan med UML. Svagheter i UML anses vara avsaknaden av processdiagram samt bristen på standardiserad syntax i verktygen. Ju längre UML har använts på företagen desto fler diagram används. De diagram som tillämpas av samtliga företag är användningsfallsdiagram, klassdiagram och sekvensdiagram. I övrigt beror användningen av diagram för ett specifikt projekt på projektets typ och storlek. Däremot utnyttjar inget av företagen UML:s flexibilitet att anpassa syntaxen. Samtliga företag kombinerar i någon utsträckning UML med RUP eller egenutvecklade utvecklingsmodeller med liknande egenskaper som RUP. Det skiljer sig dock i hur företagen använder diagrammen i samband med utvecklingsmodellerna. Detta beror troligtvis på det iterativa sätt företagen arbetar efter där diagrammen följer med i hela systemutvecklingsprocessen.

Databaser är vanligt förekommande i vardagen på företag och organisationer. De mer objektorinterade krav som idag ställs på vad en databas bör klara av att hantera, har med ökad datakapacitet gjort att mer komplexa dataobjekt måste kunna hanteras i databasen. 1990 skrevs ett manifest av den tidens ledande databasforskare om vad de ansåg att den tredje generationens databaser borde ha för funktionalitet. I detta arbete undersöks det huruvida dagens moderna relationsdatabasprodukter klarar av att hantera de krav som ställdes i manifestet på vad den tredje generationens databaser borde klara av. Arbetet utgår ifrån manifestets krav och utförs med hjälp av en kombination av metoderna litteraturstudie och implementation. Fokus har lagts på att hitta en lösning i litteraturen för att om möjligt visa med kodexempel hur det kan se ut i en praktisk lösning.

<p>System som bygger på en underliggande databas behöver ett abstraktionslager mellan databasen och applikationen. Detta kallas för systemets datalager.</p><p>Det är inte ovanligt att en stor del av programmerarnas tid går åt för att skriva programkod som hanterar datalagrets egenheter och för att transformera data mellan applikationen och datalagret.</p><p>I ett objektorienterat datalager kan systemets domänmodell integreras i datalagret så att det blir betydligt enklare och mer effektivt att arbeta med. Ett objektorienterat datalager låter dessutom applikationen navigera mellan objekten i databasen som om hela objektgrafen vore tillgänglig i applikationens primärminne. Hur information hämtas, när den hämtas och precis vilken information som hämtas från databasen är transparent för applikationen.</p><p>Det är också transparent när uppdateringar som görs på objekt i applikationens primärminne når den underliggande databasen. Datalagret ger garantin att alla objekt, som förändrats inom loppet av en transaktion och som är nåbara via navigering från något objekt i databasen, kommer att finnas i databasen med korrekt tillstånd då transaktionen avslutas.</p><p>Ett objektorienterat datalager erbjuder således en striktare form av abstraktion än vad ett traditionellt datalager gör.</p><p>Inom ramen för examensarbetet har jag utvecklat en prototyp av ett objektorienterat datalager, och i den här rapporten presenterar jag: några allmänna koncept som rör datalager i allmänhet och objektorienterade datalager i synnerhet; hur dessa koncept kan designas; samt en kort översikt av prototypen.</p>

När man kombinerar ett objektorienterat programmeringsspråk och en relationsdatabas uppstår en del problem för utvecklare eftersom objektorienterade programmeringsspråk och relationsdatabaser har olika fokus, objektorienterade programmeringsspråk fokuserar på att avbilda verkliga objekt och relationsdatabaser fokuserar på data. De problem som uppstår kallas med ett samlingsnamn för object-relational mismatch. Det finns flertalet ramverk för att hantera dessa problem. Ett av dem är Entity Framework.Syftet med detta projekt var att utvärdera hur utvecklare tycker att Entity Framework fungerar för att lösa problematiken runt object-relational mismatch, hur det är för utvecklare att lära sig använda Entity Framework samt hur tillgången på inlärningsmaterial är.Under vår studie har vi lärt oss använda Entity Framework samtidigt som vi gjort en studie av tillgången på inlärningsmaterial. Vi har också byggt om en applikation så att den använder Entity Framework. Vi har jämfört den ombyggda applikationen med den gamla applikationen för att kunna se vilken skillnad som Entity Framework bidrog till.Vi kom fram till att Entity Framework hanterar object-relational mismatch på ett bra sätt som bland annat gör att utvecklingsprocessen kortas ner då inte lika mycket kod behöver skrivas. Utvecklare med tidigare kunskaper i .NET-programmering upplever att det är lätt att lära sig Entity Framework. Att det upplevs lätt att lära sig Entity Framework hänger förmodligen ihop med att tillgången på inlärningsmaterial är god.

<p>Det blir allt mer vanligt förekommande att utvecklingen av applikationer sker enligt objektorienterade metoder, ofta som komponentbaserade applikationer. Samtidigt är användandet av traditionella relationsdatabaser fortfarande mycket utbrett. En kombination av komponentbaserad applikation och traditionell relationsdatabas har idag blivit vanlig. Här beskrivs en designstruktur som visar hur beteendet, vilket inte kan lagras i relationsdatabasen, bör tas om hand för att möjliggöra delad åtkomst samt återanvändning av programkoden. Beteendet implementeras som applikationens programkod i form av regler, beräkningar och operationer. Det har tagits i beaktning både hur uppdelningen av olika typer av beteende kan göras och var i systemet det bör implementeras, för att uppnå en generell lösning. För att underlätta framtagandet av applikationer med den framtagna designstrukturen, beskrivs de olika arbetsmoment som ingår. I lösningen används ett mellanlager med transaktionshanterare samt resurshanterare. Resultatet visar att designstrukturen fungerar för alla möjliga grundläggande konstruktioner som används i den beskrivna tekniken.</p>

<p>Utvecklingen inom IT-området har under de senaste åren varit explosionsartad. Allt fler branscher har börjat att leta efter nya sätt att tillämpa de olika framsteg som skett inom området</p><p>Detta arbete behandlar en kombinerad litteraturstudie och intervjuundersökning kring objektorientering och Business Process Reengineering. Problemställningen för detta arbete har varit:</p><p>- På vilka sätt kan objektorientering tillämpas för att utveckla de synsätt och de metoder som används inom Business Process Reengineering</p><p>Syftet med arbetet var att hitta ett antal generella tillämpningsområden utifrån problemställningen, samt att hitta ett antal fördelar, som dessa generella tillämpningar skulle kunna medföra.</p><p>Resultatet av detta arbete visar att det finns områden inom Business Process Reengineering, där en objektorienterad tillämpning skulle kunna medför stora fördelar. Som exempel på detta kan nämnas förbättrade möjligheter att skapa och anpassa de informationssystem som skall stötta verksamhetsprocesserna. Även möjligheterna att skapa dynamiska metoder, där varje metodsteg utgörs av färdiga moduler som sedan kombineras, bör nämnas som en fördel.</p>

<p>In the end of the 80´s the area of system development moved into a new era. As a consequence many new methods and development models emerged which in many cases resulted in problems when choosing system development models and methods. As a result of these problems the today standardized modeling language UML (Unified Modeling Language) was created. UML is tailored to support many different types of projects. This is possible because of UML’s capacity to be adjusted and adapted to a specific company environment.</p><p>The purpose of this bachelor thesis is to investigate how and why companies use UML and what experiences and opinions those who use UML have of using UML in practice. To fulfill our purpose we have chosen to carry out a qualitative study with semistandardized interviews. The interviews were accomplished on four companies in Jönköping. The result of the research shows that the primary reason for companies to carry out modeling is because it results in good documentation which makes development, administration and operation easier. Furthermore, the study has shown that the reason that companies have chosen UML is because it is a standard which is suited for various different projects and also for the development model used in the company. The standardization is also, according to all companies, the primary strength with UML.</p><p>Weaknesses in UML are considered to be the lack of process diagrams and standardized syntax in modeling tools. There was found to be an increase in the number of diagrams used the longer the companies have used UML. The diagrams applied by all companies are: use case diagram, class diagram and sequence diagram. Moreover, the use of diagrams for a specific project is dependent on the project type and size. However, none of the companies utilize the flexibility to adjust the syntax. All companies combine UML with RUP or business customized development models with characteristics from RUP. There is, however, a difference in how companies use the diagrams in combination with the development models. This probably depends on the companies’ iterative way of working where the diagrams are involved in the whole system development process.</p> / <p>I slutet av 80-talet gick systemutvecklingen in i ett nytt skede. Detta fick som följd att många nya metoder och utvecklingsmodeller för systemutveckling skapades vilket i flera fall ledde till problem vid val av systemutvecklingsmetod och modell. Till följd av detta skapades det idag standardiserade modelleringsspråket UML (Unified Modeling Language). UML är anpassat för att stödja många olika typer av projekt eftersom det tillåter företagsspecifika anpassningar och förändringar.</p><p>Syftet med studien är att undersöka hur och varför företag använder sig av UML samt vilka erfarenheter och uppfattningar de som arbetar med UML har av att tillämpa det i praktiken. För att uppfylla syftet har vi valt att genomföra en kvalitativ studie med semistandardiserade intervjuer. Intervjuerna utfördes på fyra företag i Jönköpingsregionen.</p><p>Resultatet av studien visar att den främsta anledningen till att företag modellerar är att det ger en bra dokumentation vilket underlättar utveckling, förvaltning och drift. Vidare har studien visat att UML har valts på grund av att det är en standard som lämpar sig för många olika projekt samt för att UML passar den utvecklingsmodell som tillämpas på företaget. Standardiseringen är även enligt samtliga företag den främsta styrkan med UML. Svagheter i UML anses vara avsaknaden av processdiagram samt bristen på standardiserad syntax i verktygen.</p><p>Ju längre UML har använts på företagen desto fler diagram används. De diagram som tillämpas av samtliga företag är användningsfallsdiagram, klassdiagram och sekvensdiagram. I övrigt beror användningen av diagram för ett specifikt projekt på projektets typ och storlek. Däremot utnyttjar inget av företagen UML:s flexibilitet att anpassa syntaxen.</p><p>Samtliga företag kombinerar i någon utsträckning UML med RUP eller egenutvecklade utvecklingsmodeller med liknande egenskaper som RUP. Det skiljer sig dock i hur företagen använder diagrammen i samband med utvecklingsmodellerna. Detta beror troligtvis på det iterativa sätt företagen arbetar efter där diagrammen följer med i hela systemutvecklingsprocessen.</p>

System som bygger på en underliggande databas behöver ett abstraktionslager mellan databasen och applikationen. Detta kallas för systemets datalager. Det är inte ovanligt att en stor del av programmerarnas tid går åt för att skriva programkod som hanterar datalagrets egenheter och för att transformera data mellan applikationen och datalagret. I ett objektorienterat datalager kan systemets domänmodell integreras i datalagret så att det blir betydligt enklare och mer effektivt att arbeta med. Ett objektorienterat datalager låter dessutom applikationen navigera mellan objekten i databasen som om hela objektgrafen vore tillgänglig i applikationens primärminne. Hur information hämtas, när den hämtas och precis vilken information som hämtas från databasen är transparent för applikationen. Det är också transparent när uppdateringar som görs på objekt i applikationens primärminne når den underliggande databasen. Datalagret ger garantin att alla objekt, som förändrats inom loppet av en transaktion och som är nåbara via navigering från något objekt i databasen, kommer att finnas i databasen med korrekt tillstånd då transaktionen avslutas. Ett objektorienterat datalager erbjuder således en striktare form av abstraktion än vad ett traditionellt datalager gör. Inom ramen för examensarbetet har jag utvecklat en prototyp av ett objektorienterat datalager, och i den här rapporten presenterar jag: några allmänna koncept som rör datalager i allmänhet och objektorienterade datalager i synnerhet; hur dessa koncept kan designas; samt en kort översikt av prototypen.

Det blir allt mer vanligt förekommande att utvecklingen av applikationer sker enligt objektorienterade metoder, ofta som komponentbaserade applikationer. Samtidigt är användandet av traditionella relationsdatabaser fortfarande mycket utbrett. En kombination av komponentbaserad applikation och traditionell relationsdatabas har idag blivit vanlig. Här beskrivs en designstruktur som visar hur beteendet, vilket inte kan lagras i relationsdatabasen, bör tas om hand för att möjliggöra delad åtkomst samt återanvändning av programkoden. Beteendet implementeras som applikationens programkod i form av regler, beräkningar och operationer. Det har tagits i beaktning både hur uppdelningen av olika typer av beteende kan göras och var i systemet det bör implementeras, för att uppnå en generell lösning. För att underlätta framtagandet av applikationer med den framtagna designstrukturen, beskrivs de olika arbetsmoment som ingår. I lösningen används ett mellanlager med transaktionshanterare samt resurshanterare. Resultatet visar att designstrukturen fungerar för alla möjliga grundläggande konstruktioner som används i den beskrivna tekniken.