/university-work/uu/software architecture/final/08_development_view.tex

https://github.com/bdumitriu/playground · LaTeX · 73 lines · 66 code · 6 blank · 1 comment · 0 complexity · 8a8f04a2249011913cd9a4495e0734ad MD5 · raw file

  1. \chapter{Development View}
  2. The placement of components into a system is not always the same as the diagram of the
  3. Logical View. It might be possible that two programs make use of the same set of packages.
  4. The Development View shows how these packages/components are distributed among the system.
  5. It also shows at which time the different subsystems have to be finished in order to
  6. succeed in developing the system as a whole.
  7. % De rest van de development viewpoint
  8. \section{Information}
  9. The development view on this system is nearly the same as the logical view,
  10. but some of the components that form the final STIFF system have to be developed
  11. as a part of UCIS.\\
  12. \\
  13. The STIFF system will do many proposal calculations during a single day. If the product
  14. information inside the database doesn't change very often (which is the case here), it
  15. is useless to query the database at every calculation request for the same product data.
  16. This is why we decided that the product data should be kept in memory of the STIFF system,
  17. and only if the product data is changed, that the STIFF systems refresh their data with
  18. the new product information. Because the actual amount of STIFF systems is never known
  19. by UCIS, there has to be some functionality which can tell all the STIFF systems to update
  20. their memory. This is done by the STIFF Notifier.\\
  21. The STIFF Notifier, which is part of the STIFF system, has to be developed
  22. as a part of the business logic of UCIS. The STIFF Notifier will receive a message from UCIS
  23. when the product information is changed in the database. The Notifier now sends a broadcast
  24. message to all the STIFF systems to update their memory, and all the systems behind the
  25. load-balancing mechanism receive the update message.\\
  26. \\
  27. In figure \ref{fig:development_final} you can see the deployment of the components of
  28. UCIS and STIFF.
  29. \begin{figure}[ht]
  30. \centering
  31. \includegraphics[width=1.00\textwidth]{img/development-final.png}
  32. \caption{Development View of UCIS and STIFF}
  33. \label{fig:development_final}
  34. \end{figure}
  35. \section{Evolution in time}
  36. The time schedule in which the system has to be developed, can be shown best in the next Gantt
  37. diagram (see figure \ref{fig:gantt}). In the first phase, the system has to be altered in a way
  38. that it will perform direct requests (on demand) instead of batch-wise calculating the proposals.
  39. To provide this functionality, both UCIS and STIFF have to be changed. UCIS will have some minor
  40. changes, just the ones for benefiting of the real-time calculations of STIFF. STIFF on the
  41. other hand, will need some major refactoring to be done to ensure real-time calculations. The
  42. whole system has to be transformed from Cobol into Java. Since this is too big of a step, we will
  43. wait with the refactoring of STIFF until the third phase. In this first phase, STIFF will receive
  44. a wrapper which starts the system on demand, and that just lets STIFF make use of its old components.\\
  45. In this first phase, we also want to insert all the customer information of the customers of ForSure
  46. into the Database of Zeker en Vast. Since the Oracle database isn't depending on ProD for storing
  47. the actual insurances (the ProD doesn't keep track of pricing fluctuations for instance),
  48. the policies of the customers of ForSure can be added to the customer database without any problem.\\
  49. \\
  50. In the second phase, the whole UCIS system will be refactored. It will get a new user interface
  51. which will be accessible through the Internet, and all the business logic that had become part
  52. of the client program will be put inside the main UCIS system again. Also, when the new GOC
  53. component is available, it will be added to the system in this phase. The last action in this
  54. phase is to make sure the CHIPS and BuRP system make use of the new interfaces that will be
  55. provided in the new UCIS system.\\
  56. \\
  57. In the third phase the STIFF system will be refactored. From now on, the STIFF system will be
  58. totally scalable, and adding extra servers to provide more computational power will be very easy.
  59. When STIFF is refactored, it will no longer make use of the old ProD database. All the product-data
  60. will be stored in the main Oracle Database from this point on. When changes are made to the
  61. products, the STIFF systems will be automatically be notified by the UCIS system of that.
  62. \begin{figure}[ht]
  63. \centering
  64. \includegraphics[width=1.00\textwidth]{img/gantt.png}
  65. \caption{Gantt diagram for the development of the system}
  66. \label{fig:gantt}
  67. \end{figure}