System Design For Service Request Management System
Registration:
The system design is done for visualizing the static and structural properties of the system. The UML diagrams are the main tool for developing the dynamic and static patterns of an object oriented system. The UML diagrams are often used in the design phase of other object based systems.
The system has been developed based on the information of IT Solutions and their need for new system. The organization requires a new system that can hold the information of the service requests and progress status of the request.
Registration:
Figure 1: Use Case Diagram of Registration
(Source: Created by Author)
Use Case Name |
Register |
|
Use Case ID |
Client01 |
|
Precondition |
Client has no existing account |
|
Activity |
Client |
System |
Open System |
||
Click on Register |
||
Fill Registration Form |
||
Submit Form |
||
Validate Data |
||
Store Data |
||
Complete Registration |
||
Post-condition |
Client account is created |
|
Exception |
Client connection lost |
Figure 2: Use Case Diagram of Status Update
(Source: Created by Author)
Use Case Name |
Status Update |
||
Use Case ID |
Consultant |
||
Precondition |
Consultant is logged in Consultant is working on this request |
||
Activity |
Consultant |
Client |
System |
Open System |
|||
Click on Request Status Update |
Redirect to Status Update Form |
||
Complete? |
|||
Input Status |
Update Status |
||
Mark as Complete |
Accept Solution |
Close Request |
|
Reject Solution |
Update Status |
||
Post-condition |
Status updated and informed to client |
||
Exception |
Request is withdrawn by client |
Figure 3: Use Case Diagram of Enter New Service
(Source: Created by Author)
Use Case Name |
Enter New Service |
|
Use Case ID |
Client03 |
|
Precondition |
Client is logged in |
|
Activity |
Client |
System |
Open System |
Check user login session |
|
Register if not registered |
||
Otherwise Login |
Start Session |
|
Open New Service Request Page |
||
Submit Form |
Validate Request Data |
|
Store Request |
||
Post-condition |
New request stored |
|
Exception |
Problem is not supported |
Figure 4: Activity Diagram of Registration
(Source: Created by Author)
In this diagram the client seems to start the system. Opening of the system is done. After opening the system the client clicks on the register. After clicking on the register the register is filled. After filling of the firm is done. After submitting of the form tasks that are to be done from the client ends gets completed. After this the phase the entire functioning of the project is completed from the system. In the initial stage validation of the data are done. Storing of data will be performed after the validation of the data. After storing of the data, the registration process gets completed. After this aspect the entire processing ends.
Figure 5: Activity Diagram of Update Request Status
(Source: Created by Author)
In this diagram 3 objects are noticed. The objects are namely the consultant, clients, system. The entire process starts off in the consultant phase. The process starts in the open system. After the open system, clicking on the request status update is performed. After checking the request, the entire phase shifts to the system. After the system processing can be performed with the help of the redirection of the status update form. Again the entire phase is seem to shift to the consultant phase. Decision making is doe in this stage. In case the redirection of the updated form is completed the stage reaches to the completion stage and the process is marked to be complete. In case the redirection of the status update form is not checked the main processing that is to be performed includes better prosecution of the input status. After the prosecution of the marking process again the decision making stage emerges. After this process the client phase is projected. In the client phase decision regarding the acceptability of the solution is checked. In case the solution is accepted, the request closes and in case the solution is not accepted, the status gets updated. After accepting of the request the task ends
Use Case Diagram of Registration
Figure 6: Activity Diagram of Enter New Service Request
(Source: Created by Author)
In this diagram the entire diagram is diversified in 2 objects, namely the client phase and the system phase. In the client phase the project starts. After starting of the project, the system opens. Decisions is made regarding the registering of the client. In case the client is registered the client reaches to the log in page. After checking of the registration status, in case the registration is not performed, registration of the client is done. After registering of the client the client reaches the log in page. After reaching the log in page, a new service request page opens up. After opening of the request page, the form is submitted. After this stage the entre phase shifts from the client phase to the system phase. Validation of the requested data is performed and the request is made to store the data. After this stage the entire task ends.
Figure 7: Sequence Diagram of Registration
(Source: Created by Author)
Two objects are seen in this sequence diagram. In this diagram, client end and User management is taken into consideration. The client registers to the user management. After registering to the user management. After getting the register form, submission of the form is performed. After submission of the form, date validation is performed. The data validation is termed to be successful in case the registration is successful. In case the registration is unsuccessful, resubmission of the form is done.
Figure 8: Sequence Diagram of Update Request Status
(Source: Created by Author)
In this case four objects are taken into consideration. The four objects are namely consultant, client, and request and user management. The consultant updates status and request is made. After updating the status, checkLogin() message is provided to the user management. Checking of session is made and the user management logs in. After checking status validity the status is updated. After checking the status, problem solving is done. In case the problem that is solved gets accepted the process passes on. In case the status validity is checked, user management is processed.
Figure 9: Sequence Diagram of Enter New Service Request
(Source: Created by Author)
This diagram is basically diversified in 2 stages. In the client stage, new service request is sent. From the request stage, request form is sent. The form is submitted. After sending of the submitted form, validation of the request is performed as per the data management. The data validation is diversified as per the successful and the unsuccessful process. The store request is sent and the request is accepted. In case of the unsuccessful result outcome, the request for changing data is made, the inputs that are invalid in nature are provided. The form is submitted again after correction.
Use Case Diagram of Status Update
Figure 10: Domain Model Class Diagram
(Source: Created by Author)
The domain model class diagram shows the structural pattern of the IT solution’s proposed system. The system has four main classes named as client, userManagement, request and consultant. The client class, request class, userManagement class and consultant class stores the client data, service request data, consultant data and userManagement data respectively. userManagement class stores the login id and password data of the users. This class id is formed using the consultant and client class. That is why the composition relationship has been used in the diagram. A client may not enter a service request.
Figure 11: State Machine Diagram
(Source: Created by Author)
The state machine diagram shows that there are seven states in the system. Each state is defined using a message. The first state is submission of request. The whole process completes when the client accepts the request and system closes the request.
Figure 12: User Interface Diagram
(Source: Created by Author)
Conclusion:
The study concludes that the proposed system is capable of providing an effective solution. The diagrams are very clear and provide a proper idea of what the system will do. Every design is based on the objectives of the IT Solutions organization. The interface shows that the system can integrate a mobile interface. The design shows that the system will validate every input it accepts and then store it to the database. The description of the use cases has provided a good idea of the system.
Cunha, A., Garis, A. and Riesco, D., 2015. Translating between Alloy specifications and UML class diagrams annotated with OCL. Software & Systems Modeling, 14(1), pp.5-25.
Decker, M.J., Swartz, K., Collard, M.L. and Maletic, J.I., 2016, October. A tool for efficiently reverse engineering accurate UML class diagrams. In 2016 IEEE International Conference on Software Maintenance and Evolution (ICSME) (pp. 607-609). IEEE.
Dennis, A., Wixom, B.H. and Tegarden, D., 2015. Systems analysis and design: An object-oriented approach with UML. John wiley & sons.
Faitelson, D. and Tyszberowicz, S., 2017, May. UML Diagram Refinement (focusing on class-and use case diagrams). In Proceedings of the 39th International Conference on Software Engineering (pp. 735-745). IEEE Press.
Felderer, M. and Herrmann, A., 2015. Manual test case derivation from UML activity diagrams and state machines: A controlled experiment. Information and Software Technology, 61, pp.1-15.
Fernandez-Saez, A.M., Genero, M., Caivano, D. and Chaudron, M.R., 2016. Does the level of detail of UML diagrams affect the maintainability of source code?: a family of experiments. Empirical Software Engineering, 21(1), pp.212-259.
Fernandez-Saez, A.M., Genero, M., Chaudron, M.R., Caivano, D. and Ramos, I., 2015. Are Forward Designed or Reverse-Engineered UML diagrams more helpful for code maintenance?: A family of experiments. Information and Software Technology, 57, pp.644-663.
Gogolla, M., Hilken, F., Niemann, P. and Wille, R., 2017, July. Formulating model verification tasks prover-independently as UML diagrams. In European Conference on Modelling Foundations and Applications (pp. 232-247). Springer, Cham.
Granda, M.F., Condori-Fernandez, N., Vos, T.E. and Pastor, O., 2016, June. Mutation operators for UML class diagrams. In International Conference on Advanced Information Systems Engineering (pp. 325-341). Springer, Cham.
Setyautami, M.R., Hähnle, R., Muschevici, R. and Azurat, A., 2016, September. A UML profile for delta-oriented programming to support software product line engineering. In Proceedings of the 20th International Systems and Software Product Line Conference (pp. 45-49). ACM.
Torre, D., Labiche, Y., Genero, M. and Elaasar, M., 2018. A systematic identification of consistency rules for UML diagrams. Journal of Systems and Software.
Torre, D., Labiche, Y., Genero, M., Baldassarre, M.T. and Elaasar, M., 2018, May. UML diagram synthesis techniques: a systematic mapping study. In 2018 IEEE/ACM 10th International Workshop on Modelling in Software Engineering (MiSE) (pp. 33-40). IEEE.