System Design Case Model in Real World

Question: Describe about the System Design for Case Model in Real World. Answer: 1. Information Needed for Development of Use Case Model in Real World The developmental perspective of the use case model considers the real world application (Kulak and Guiney, 2012). This aspect introduces mainly three factors within it to make the impact of the use case model clear on the real world (Ambler, 2012). The use case model generally considers actors of the case, identification of the use case and interrelation of the actors within the use case. These three aspects specify the impact of the use case real life situations. According to the case study, actors are the card users: child, pensioners and adults and the use case is the information transfer of user data related to swipe in and swipe out of travel cards. 2. Use Case Diagram Figure 1: Use Case Diagram for Traveling Card Payment System (Source: Created by author) Use case list Use case ID Primary Actor Use Cases UC 1 Child user, Pensioner and Adult users Swipe in details UC 2 Child user, Pensioner and Adult users Swipe out details UC 3 Child user, Pensioner and Adult users Type of the users UC 4 Child user, Pensioner and Adult users Arrival UC 5 Child user, Pensioner and Adult users Destination UC 6 Admin Payment validation UC 7 Admin Payment calculation System Name: Travel Swipe Card Transaction System UC 1, UC 2 Use Case ID UC 1, UC 2 Use Case Name Swipe in details and Swipe out details Created by Date created Actors Primary actors are: Child user, Pensioner and Adult users Secondary actors are: Admin Description This use case checks the swiping in and swipe out details of the users in the station that decides their stating point of the journey. Trigger UC1- Entry of the user in the station UC2- Check out of User Preconditions User must enter to the station User must be registered with the system User must have swipe card Normal Flow At the first step the user chose the tram system for reaching his destination. After this the user swipes in the card by entering to the station and his arrival point and destination is recorded in the server. At the end of journey the user swipes the card for checking out of the station. Alternative Flows Internet Threat: If the systems get affected by the virus then the system can get protected by placing bridge in between the user and admin server. Exceptions Blocking of swipe card: There is always a separate master card to recover the blocking. Transactional error: The admin server passes a signal to overcome the transactional error with the swipe card. Includes Destination selection: The destination is entered by the user after swiping the card. Type of the user: User type is also entered by the user. Frequency of Use Once in a year Special Requirements The swipe card must be aware of the identification and authentication of the user while calculating the fare it should be 95 %. Transactional error must be avoided on first priority it should be about 90%. Assumptions Users understand either English or the regional Language. Notes and Issues Delayed transaction of fare Software support to user UC3, UC4, UC5 Use Case ID UC 3, UC 4, UC 5 Use Case Name Type of User, Arrival and Destination selection Created by Date created Actors Primary actors are: Child user, Pensioner and Adult users Secondary actors are: Admin Description The user enters the type of them and then the arrival and destination point entered. Triggers Entry of the user in the station Preconditions User must enter to the station User must be registered with the system User must have swipe card Normal Flow At the first step the user chose the tram system for reaching his destination. User swipes the card and enters the destination station. Alternative Flows Internet Threat: If the systems get affected by the virus then the system can get protected by placing bridge in between the user and admin server. Exceptions Blocking of swipe card: There is always a separate master card to recover the blocking. Transactional error: The admin server passes a signal to overcome the transactional error with the swipe card. Includes Destination selection: The destination is entered by the user after swiping the card. Type of the user: User type is also entered by the user. Frequency of Use Once in a year Special Requirements The swipe card must be aware of the identification and authentication of the user while calculating the fare it should be 95 %. Transactional error must be avoided on first priority it should be about 90%. Assumptions Users understand either English or the regional Language. Notes and Issues Delayed transaction of fare Software support to user UC 6, UC 7 Use Case ID UC 6, UC 7 Use Case Name Payment validation and payment calculation Created by Date created Actors Primary actors are: Admin Secondary actors are: child, pensioner and adult Description The admin checks the validity of the payment and then calculate the fare according to the type and destination of the user. Triggers Entry of the user in the station Preconditions User must enter to the station User must be registered with the system User must have swipe card Normal Flow At the first step the user chose the tram system for reaching his destination. User swipes the card and enters the destination station. The admin take information and validate and calculate the fare for the user. Alternative Flows Exceptions Blocking of swipe card: There is always a separate master card to recover the blocking. Transactional error: The admin server passes a signal to overcome the transactional error with the swipe card. Includes Payment details: these two use cases checks the payment confirmation and calculation aspect. Frequency of Use Once in a year Special Requirements The swipe card must be aware of the identification and authentication of the user while calculating the fare it should be 95 %. Transactional error must be avoided on first priority it should be about 90%. Assumptions Users understand either English or the regional Language. Notes and Issues Delayed transaction of fare Software support to user 3. Use Case Diagram for Adult Users Figure2: Use Case Diagram for Adult Users (Source: Created by author) Use case 3: Swipe In Details Use Case ID UC 1 Use Case Name Swiping in details Created by Date created Actors Primary actors are: Child user, Pensioner and Adult users Secondary actors are: Admin Description The user enters the type of them and then the arrival point entered. Triggers Entry of the user in the station Preconditions User must enter to the station User must be registered with the system User must have swipe card Normal Flow At the first step the user chose the tram system for reaching his destination. The arrival point is informed to the admin. Alternative Flows Internet Threat: If the systems get affected by the virus then the system can get protected by placing bridge in between the user and admin server. Exceptions Blocking of swipe card: There is always a separate master card to recover the blocking. Transactional error: The admin server passes a signal to overcome the transactional error with the swipe card. Includes Destination selection: The destination is entered by the user after swiping the card. Type of the user: User type is also entered by the user. Frequency of Use Once in a year Special Requirements The swipe card must be aware of the identification and authentication of the user while calculating the fare it should be 95 %. Transactional error must be avoided on first priority it should be about 90%. Assumptions Users understand either English or the regional Language. Notes and Issues Delayed transaction of fare Software support to user References Ambler, S., 2012.Agile database techniques: Effective strategies for the agile software developer. John Wiley Sons. Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Alarcon, M.P., Bakker, J., Tekinerdogan, B., Clarke, S. and Jackson, A., 2015. Survey of aspect-oriented analysis and design approaches. Conforti, V., Antolini, E., Bonnoli, G., Bruno, P., Bulgarelli, A., Capalbi, M., Fioretti, V., Fugazza, D., Gardiol, D., Grillo, A. and Leto, G., 2016, July. Software use cases to elicit the software requirements analysis within the ASTRI project. InSPIE Astronomical Telescopes+ Instrumentation(pp. 991340-991340). International Society for Optics and Photonics. Ghaisas, S., Motwani, M. and Anish, P.R., 2013, November. Detecting system use cases and validations from documents. InAutomated Software Engineering (ASE), 2013 IEEE/ACM 28th International Conference on(pp. 568-573). IEEE. Holmberg, C., Hakansson, S. and Eriksson, G., 2015.Web real-time communication use cases and requirements(No. RFC 7478). Klingensmith, N., Willis, D. and Banerjee, S., 2013, November. A distributed energy monitoring and analytics platform and its use cases. InProceedings of the 5th ACM Workshop on Embedded Systems For Energy-Efficient Buildings(pp. 1-8). ACM. Kulak, D. and Guiney, E., 2012.Use cases: requirements in context. Addison-Wesley. Laghari, K.U.R. and Connelly, K., 2012. Toward total quality of experience: A QoE model in a communication ecosystem.IEEE Communications Magazine,50(4), pp.58-65. Rago, A., Marcos, C. and Diaz-Pace, J.A., 2016. Identifying duplicate functionality in textual use cases by aligning semantic actions.Software Systems Modeling,15(2), pp.579-603. Shiramatsu, S., Tossavainen, T., Ozono, T. and Shintani, T., 2015, August. Towards Continuous Collaboration on Civic Tech Projects: Use Cases of a Goal Sharing System Based on Linked Open Data. InInternational Conference on Electronic Participation(pp. 81-92). Springer International Publishing. Spitzer, M. and Ebner, M., 2016, June. Use cases and architecture of an information system to integrate smart glasses in educational environments. InEdMedia: World Conference on Educational Media and Technology(Vol. 2016, No. 1, pp. 51-58). Villaveces, J.M., Jimenez, R.C., Porras, P., del-Toro, N., Duesbury, M., Dumousseau, M., Orchard, S., Choi, H., Ping, P., Zong, N.C. and Askenazi, M., 2015. Merging and scoring molecular interactions utilising existing community standards: tools, use-cases and a case study.Database,2015, p.bau131