Migration of a Chosen Architectural Pattern to Service Oriented ...

Chapter 5. Guidelines 123FrontendFrontendProcess AbstractionUI-MediatorInventory EndpointsProcess AbstractionInventory EndpointsSchemaPolicySchemaPolicyBasic ServicesUtilityResources+ UI-Mediator=Basic ServicesUtilityEntityResourcesRulesEntityStateRulesStateFigure 5.13: Migration step 13in practise. Application of the guidelines along with comments supplements thetheoretical description. This section presents briefly criteria applied in order toselect the project for migration along with description of the project.5.3.1 Selection CriteriaSelection of the example project is conducted according following criteria:1. The system must have documentation with models including at least overviewof architecture and flows of business processes.2. The system must implement MVC architectural pattern3. The system cannot be build using frameworks supporting MVCThe first criterion is motivated by a need of reverse engineering if the documentationis missing. This is the first criterion because the guidelines requiredocumentation. All projects that do not have documentation are rejected. Howeverreverse engineering is very useful when documentation is missing and it evenwas employed in migration toward services [61], it is still associated with an additionaleffort. Results of Reverse Engineering may also not be satisfactionaryand do not motivate decisions taken during design time of the project. Reverseengineering presented in [61] serves also to reconstruct architecture. There is apossibility of identification of architectural patterns when the process is finished,but again there is no possibility to clearly state whether the identified pattern