Spelling suggestions: "subject:"refactoring estrategy"" "subject:"refactoring astrategy""
1 |
RefStratERP – A Refactoring Strategy for ERP SystemsPetkovic, Nikola January 2017 (has links)
Enterprise Resource Planning (ERP) systems are used to integrate all functions of an enterprise. They often evolve from a smaller monolithic object-oriented application, covering one functional area and organically grow over time in features and size until all functional areas are covered. Once they reach certain size, unrestricted dependencies among numerous classes increase complexity of the system and make it harder for development team to create new features and maintain code stability. This creates problems to further evolution of the ERP system and poses a risk to economic consequences for company developing it. ERP refactoring strategy, together with process of its creation, is presented in this thesis. It can be used with ERP systems, having architectural issues, with a purpose to improve quality of system’s architecture and thus prolong its lifecycle. The goal of modularizing monolithic system it pursued with intention to reduce complexity and make it easier to reason about the system. This architecture-level refactoring strategy is created for one specific medium-sized ERP system through iterative trial-and-error explorative approach. This thesis is carried out at the main development site for this ERP system by project team consisting of employees working on its development. The result shows the RefStratERP, an innovative refactoring strategy consisting of target architecture, refactoring process to reach it, refactoring principles and refactoring limitations. Contrary to initial expectation, arranging domain modules (modules containing business logic) in directed acyclic graph (DAG) is, in general, not feasible without sacrificing internal module cohesion of business logic. Accidental unidirectional dependency between two domain modules is at risk of becoming bidirectional under changing business requirements. On the other hand, non-domain modules (modules without business logic) could be completely separated from domain modules in a way that domain modules depend on non-domain modules. This comes from underlying nature of business domain and the fact that functional areas of an enterprise are interdependent. / Enterprise Resource Planning-system (ERP) används för att integrera alla funktioner inom ett företag. Oftast utvecklas dem från en mindre monolitisk objektorienterad applikation som täcker ett funktionellt område och växer organiskt över tiden i funktioner och storlek tills alla funktionella områden är täckta. När dem når en viss storlek ökar komplexiteten i systemet vilket gör det svårare fär utvecklingsteamet att skapa nya funktioner och hålla kodstabilitet. Detta skapar problem för fortsatt utveckling av ERP-systemet och utgör en risk för ekonomiska konsekvenser för utvecklingsföretaget. ERP refactoringstrategin, tillsammans med processen med att skapa den, presenteras i denna avhandling. Den kan användas med ERP-system, med arkitektoniska problem, med syfte att förbättra kvaliteten hos systemets arkitektur och därigenom förlänga dess livscykel. Målet att modularisera monolitiska system strävas efter i syfte att minska komplexiteten och göra det lättare att resonera kring systemet. En refaktorstrategi på arkitektnivå skapas för ett specifikt medelstort ERP-system genom en iterativ och försök-och-mistag-explorativ metod. Projektet genomfördes på ERPs huvudutvecklingsplats av ett projektteam bestående av anställda inom ERP utveckling. Resultatet visar RefStratERP, en innovativ refaktorstrategi som består av målarkitektur, refactoringprocess för att nå det, refactoringprinciper och refactoringbegränsningar. I motsats till inledande förväntningar är det i allmänhet inte möjligt att ordna domänmoduler (moduler som innehåller affärslogik) i en riktad acyklisk graf (DAG) utan att påverka interna modulsammanhang (cohesion) i affärslogiken. Oavsiktlig enriktad beroende mellan två domänmoduler riskerar att bli dubbelriktad under förändrade affärsbehov. Å andra sidan kan icke-domänmoduler (moduler utan affärslogik) helt separeras från domänmoduler så att domänmoduler beror på icke-domänmoduler. Detta kommer från underliggande egenskaper av affärsområden och det faktum att verksamhetsområden inom ett företag är beroende av varandra.
|
Page generated in 0.1293 seconds