<p>Syftet med arbetet har varit att undersöka om en viss arkitektur kan användas för att underlätta utvecklingen av ett Back Office-system till ett befintligt och komplext verksamhetssystem.</p><p>För att gränsa av arbetet och hitta de delar som var intressanta att fokusera på genomfördes intervjuer med tre olika personer som hade olika syn på ett Back Office-system genom sin yrkesroll. Intervjuerna resulterade i ett antal önskemål för vad man ville uppnå med ett Back Office-system.</p><p>Arbetet resulterade i en arkitektur som kan användas för att underlätta utvecklingen av ett Back Office-system till det befintliga verksamhetssystemet samt till verksamhetssystemet självt. Arkitekturen har utvärderats genom att man först ställde en mängd krav på den och sedan studerade hur den klarade av en mängd nya krav som delvis var relaterade till de gamla kraven.</p><p>Alla tester som gjorts visar på att arkitekturen är väl designad och lätt att underhålla samt att den kommer underlätta den fortsatta utvecklingen av verksamhetssystemet och dess Back Office-system.</p> / <p>The purpose of this thesis has been to evaluate if an architecture could ease the development of a back office system for a present and complex business management system.</p><p>To find the most valuable parts of the system three interviews was conducted. Three different people with different interests in the system were interviewed. The result was a couple of requirements for the back office system.</p><p>The work resulted in an architecture that can ease the development of the back office system and for the business management system itself. The architecture was developed with a first set of requirements that originated from the interviews. Then the architecture was presented with a new set of requirements, also originated from the interviews, and the process of adapting the architecture to the new set of requirements was studied to see if the architecture will be easy to maintain.</p><p>All conducted test shows that the architecture is well designed and easy to maintain. They also show that the architecture will ease further development of the business management system and its back office system.</p>

Syftet med arbetet har varit att undersöka om en viss arkitektur kan användas för att underlätta utvecklingen av ett Back Office-system till ett befintligt och komplext verksamhetssystem. För att gränsa av arbetet och hitta de delar som var intressanta att fokusera på genomfördes intervjuer med tre olika personer som hade olika syn på ett Back Office-system genom sin yrkesroll. Intervjuerna resulterade i ett antal önskemål för vad man ville uppnå med ett Back Office-system. Arbetet resulterade i en arkitektur som kan användas för att underlätta utvecklingen av ett Back Office-system till det befintliga verksamhetssystemet samt till verksamhetssystemet självt. Arkitekturen har utvärderats genom att man först ställde en mängd krav på den och sedan studerade hur den klarade av en mängd nya krav som delvis var relaterade till de gamla kraven. Alla tester som gjorts visar på att arkitekturen är väl designad och lätt att underhålla samt att den kommer underlätta den fortsatta utvecklingen av verksamhetssystemet och dess Back Office-system. / The purpose of this thesis has been to evaluate if an architecture could ease the development of a back office system for a present and complex business management system. To find the most valuable parts of the system three interviews was conducted. Three different people with different interests in the system were interviewed. The result was a couple of requirements for the back office system. The work resulted in an architecture that can ease the development of the back office system and for the business management system itself. The architecture was developed with a first set of requirements that originated from the interviews. Then the architecture was presented with a new set of requirements, also originated from the interviews, and the process of adapting the architecture to the new set of requirements was studied to see if the architecture will be easy to maintain. All conducted test shows that the architecture is well designed and easy to maintain. They also show that the architecture will ease further development of the business management system and its back office system.

Websites today only offer simpler form of technical analysis and are not fun to use, therefore student decided to build a website that makes technical analysis a bit more fun by giving user possibility to experiment with settings for technical indicators and also see clear visible results from analysis. Student decided to build website in ASP.NET. Technical indicators for this project only consist of those who give buy and sell-signals via cross-over, no divergence or pattern finding.This project has three questions that define this project. It’s important that there is good functionality so that performing an analysis is perceived as simple, one question is therefore; what functionality for website is needed in order for analysis to be perceived as more simple?Technical analysis is a pretty complex subject and demands an interface that is perceived as easy to understand and easy to use, it’s therefore important that the interface is well designed, second question is therefore; how should the interface be designed to be user-friendly?When systems grow large they often become hard to develop and later on unmaintainable because of the accumulated complexity and dependency between classes, the code is a mess, the last question is therefore; how can the systems complexity be eased with object-oriented design principles?Jakob Nielsens ten heuristics for User Interface Design were used as inspiration for designing the interface for the website. The system design follows SOLID principles, some pattern-design were also used because pattern-design often fulfills SOLID principles or makes for pretty good solutions in regular code-problems.At the beginning of the project the student did a small research to find out what was needed in order to complete project. Work-method for project follows agile development where decisions were made on a weekly basis. The project was divided into three phases where each phase was strongly coupled to a specific area of responsibility. Prototypes for interface were made and used as a basis for the resulting interface.The project led to a working website with good functionality. Filter was considered as important in order to ease shaping of analysis because the user could more easily sort and pick stock. The student assumed that the user would want fast and easy access to their stock so portfolio management were implemented so that user could more easily get to stock that was considered as favorites. The interface follows to a big extent Jakob Nielsens ten heuristics for User Interface Design and is proven by comparing interface with principles. The same goes for design of the system, design is proven by comparing with principles, still to this day system is considered easy to continue development.Student made the conclusion that SOLID principles were very important in order for the system to maintain its health and took experience from these principles. Student became happy with the interface but more focus could’ve been given for a more interactive interface because it might’ve been perceived as more intuitive.

Syftet med studien är att undersöka om det går att vinna fördelar i prestanda genom att lagra data för två webbapplikationer på ett dataorienterat sätt kontra det mer klassiska objektorienterade sättet. Grundanledningen till studien är att det har upptäckts att ett dataorienterat programmeringstänk genererat prestandafördelar vad det gäller datahanteringen inom dataspelsindustrin. För att genomföra denna studie skapas två webbapplikationer som lagrar fiktiv data över kunders elkonsumtion. I nästa led klustras datan med en k-means klustringsalgoritm och exekveringstid för detta mäts och redovisas. Olika stora mängder data genererades i studien och det går det att påvisa att den dataorienterade designen av datan ger fördelar över den objektorienterade datan vad det gäller exekveringstiden. För framtida arbete så kan det vara intressant att titta på ännu större datamängder och eventuellt använda sig av fler dimensioner för att se om det skulle kunna skapa än större fördelar med en dataorienterad design kontra en objektorienterad design för webbapplikationers data.

Dagens applikationer hanterar mer och mer data vilket resulterar i att de blir allt mer resurskrävande och kräver mer av hårdvaran. Vilket i förlängningen kan innebär att hårdvaran måste bytas ut med jämna mellanrum för att kunna köra mjukvaran på ett för användaren tillfredsställande sätt. Detta arbete undersöker om det genom att byta designteknik är möjligt att utveckla mindre resurskrävande applikationer. Arbetet presenterar en jämförelse mellan objektorienterad design (även kallad objektorienterad programmering, OOP) och data orienterad design (DOD). Detta genom att dels ta upp kända för- och nackdelar med respektive designteknik samt genom att utföra en mätning på respektive teknik. Det som anses vara de främsta fördelarna med OOP är återanvändning av kod, att koden är lätt att underhålla, säkerhet i form av inkapsling samt att objekten som används reflekterar den mänskliga verkligheten. Dessa fördelar är dock även något som bidrar till det som anses vara den främsta nackdelen med OOP, nämligen att den är prestandakrävande. När det gäller DOD så anses de främsta fördelarna vara att det medför en cachevänligare kod som leder till färre cachemissar. Det anses även vara lättare att parallellisera koden i jämförelse med OOP. Den nackdelen som tas upp med DOD är att de tar tid att lära sig och kräver en del övning. Dock är DOD väldigt okänt vilket resulterade i ett svagt underlag. Två simuleringar utvecklades i Unity varav den ena använder sig av den nya teknikstacken DOTS som är dataorienterad. Resultatet av mätningarna indikerar på att DOD använder mindre av hårdvaruresurserna vid prestandakrävande applikationer. Om applikationen ej är prestandakrävande märks dock ingen skillnad mellan de olika teknikerna vid fråga om processoranvändning. / Today, applications handle more and more data, which results in them becoming increasingly resource-intensive and requiring more of the hardware. Which in the long run may cause that the hardware must be replaced at regular intervals to be able to run the software in a way that is satisfactory for the user. This thesis investigates whether it is possible to get less resource-intensive applications by changing the design technology. The paper presents a comparison between object-oriented design (also known as object-oriented programming, OOP) and data-oriented design (DOD). This is performed by addressing the known advantages and disadvantages of each design technique and by measuring each technique in the matter of performance. What was considered to be the main advantages of OOP is the reuse of code, that the code is easy to maintain, security in the form of encapsulation and that the objects that are used reflect human reality. On the other hand, these advantages also contribute to what is considered to be the main disadvantage of OOP, namely that it is performance-intensive. When it comes to DOD, the main advantages are considered to be that it results in a more cache-friendly code that leads to fewer cache misses. DOD is also considered easier to parallelize the code compared to OOP. The disadvantage of DOD is that it is time consuming to learn and requires some practice. Though, DOD is very unknown which resulted in a narrow basis. Two simulations were developed in Unity, one of which uses the new technology stack DOTS, which is data-oriented. The results of the measurements indicate that DOD uses less of the hardware resources in performance-intensive applications. If the application is not performance-intensive, though, no difference is noticed between the different technologies when it comes to CPU-usage.

Datorspel behöver utnyttja hårdvara effektivt för att kunna vara tillgänglig på så många system som möjligt med varierande kapacitet. En viktig del i detta är att optimera användandet av processorns cacheminnen. Programmerare kan följa en dataorienterad design för att implementera cacheeffektiv kod. Detta förutsätter att programmeraren har kontroll över hur data lagras i minnet, vilket är svårt att uppnå i Java. Project Valhalla kan erbjuda funktioner för att åtgärda detta problem. I detta arbete jämfördes objektorienterad design med dataorienterad design i språken C++, Java och den pågående utvecklingen av Project Valhalla. En prototyp utvecklades och implementerades med olika kombinationer av dessa språk och designer. För varje implementation mättes prestanda och cacheeffektivitet. Resultatet visade att Java med Project Valhalla kan uppnå liknande prestanda som C++ vid dataorienterade implementationer. På grund av vissa begränsningar i Valhallas funktioner kommer det troligtvis inte bli ett praktiskt alternativ till lågnivåspråk inom en snar framtid. / Computer games need to utilize hardware efficiently in order to be available on as many systems as possible with varying capabilities. An important part of this is to optimize the use of the CPU’s cache. A programmer can follow a data-oriented design to implement cache-efficient code. This requires the programmer to have control over how data is stored in memory, which is difficult to achieve in Java. Project Valhalla may offer features to address this issue. In this thesis, object-oriented design was compared with data-oriented design in the languages C++, Java, and the ongoing development of Project Valhalla. A prototype was developed and implemented using different combinations of these languages and designs. For each implementation, performance and cache efficiency were measured. The result showed that Java with Project Valhalla can achieve similar performance to C++ in data-oriented implementations. Due to some limitations in Valhalla's features, it is unlikely that it will become a suitable alternative to low-level languages anytime soon.