1 / 24

TVAC Electronic Call Sheet System

TVAC Electronic Call Sheet System. Team HeatWave Summer 2007. The Paper Call Sheet. Front. Back. Advantages. Electronic data can be made more secure than paper storage with backup systems and redundancy on geographically dispersed servers Electronic call sheets can be searched instantly

stephen-maldonado
Télécharger la présentation

TVAC Electronic Call Sheet System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TVAC Electronic Call Sheet System Team HeatWave Summer 2007

  2. The Paper Call Sheet Front Back

  3. Advantages • Electronic data can be made more secure than paper storage with backup systems and redundancy on geographically dispersed servers • Electronic call sheets can be searched instantly • Data can be shared more quickly and easily with other emergency services and municipal organizations • Enables data mining for statistics that can be used to improve procedures and detect patterns

  4. System Architecture • 3-tier architecture • Built on latest Java EE framework (EE 5, EJB 3.0, JPA) • All server functionality exposed via Web Service • Built entirely with open-source components Client Internet Servlet App Server Web Containter WSB | EJB EJB Containter DB mySQL

  5. System Capabilities (Release 1) • Create call sheet • Search call sheets • View call sheet details • Edit call sheet • Delete call sheet

  6. Walk-thru: Call Sheet Creation Tom’s Restaurant

  7. 54234 Call sheet created successfully. (id=54234) Walk-thru: Call Sheet Creation

  8. Walk-thru: Call Sheet Search New York Corner of Deli

  9. View detail (driven by search selection) Walk-thru: Call Sheet Search Search selection Search results stored in JTable

  10. Critical code paths: GUI • CallSheetSearchUI : Covers 80% of use cases • Procedures followed • Blackbox testing • Boundary value analysis • Whitebox testing • Statement coverage • Branch coverage • Control flow path coverage • Data flow path coverage

  11. Critical code paths: GUI (cont) • Results obtained • Search by Call Sheet ID, location, town, date range • Boundary value errors • View call sheet detail based on JTable selection of search results • Statement, control and data flow path errors • Edit a call sheet • Control and data flow path errors • Delete call sheets • No errors

  12. Critical code paths: Controller • Requests from the client module are intercepted by the servlet and forward to the processRequest method in CallSheetServlet.java • This method draws all the subsystems together and performs the following tasks: • Reads the client’s XML request • Converts the request to a call sheet object • Invokes the appropriate database method • Returns the request result to the client • The centrality of this method and the abundance of custom code make this the most critical method of the Controller.

  13. Critical code paths: Data Store • Managed persistence and connections eliminated most of the data store “plumbing” • CallSheetFacade.java (stateless EJB) contains most of the custom logic • findBySearchCriteria() method involves building an EJB-QL query from our custom SearchCriteria object • Custom code, EJB-QL syntax, and direct coupling with the Controller make CallSheetFacade the most critical section of code in the data store

  14. Code inspection: GUI • Line by line review of the critical section • Q & A format • 17 Issues documented and prioritized in issue tracker:

  15. Code inspection: Controller • CallSheetServlet • Procedures followed • Formal code review • Results obtained • Edit and delete functionality not implemented • Missing comments • Missing / incorrect Java Doc • Dead code

  16. Code inspection: DataStore • Line by line review of the critical section, CallSheetFacade.java • Issues discovered • Dead code • Missing error handling • Missing comments

  17. Testing: Statement Adequacy Coverage • Coverage testing was done to ensure that each line of code in the critical paths was run at least once. • Due to the reduction in code size brought about by Java EE 5 and the familiarity with the code brought about by the code reviews, coverage tests were designed to reach each line and were verified with a visual debugger. • Unit, integration, and acceptance tests exercised the paths more rigorously by testing a variety of paths through the critical code

  18. Testing: GUI (CallSheetSearchUI.java) • Code for UI construction and layout does not branch • Normal testing covers the straight-line code (lines 1-131, methods CallSheetSearchUI(), draw(), createSection1(), createSection2(), and createSection3() • Updating functions require specific actions and data to achieve full code coverage (presented in the next two slides) • In the following test cases, expected results are that the application reports problems when the action cannot be performed and otherwise completes the operation successfully. • In addition to the following actions and data, perform one test case where you resize the search screen (lines 337-343).

  19. Testing: GUI (actions) Results in 27 test cases using 3 sets of data for each of the 9 boxes. Using these 27 tests, all lines of code are executed.

  20. Testing: GUI (data) When creating a representative set of data. Be sure that you have at least three records with the following fields set as indicated. This data will ensure that the specified lines of code are covered.

  21. Testing: GUI (data) We ensured that all code is covered by tests as indicated in the charts above. However, to gain full confidence in the code it was necessary to cover some of the same lines of code but by following different code paths to get there. Tests described here were designed to skip lines of code to see the impact when those lines are not executed.

  22. Testing: Controller • Procedures followed • Create call sheet • Search for call sheets • View call sheet detail • Edit a call sheet • Delete call sheets

  23. Testing: Controller (cont) • Results obtained • Create call sheet <CallSheetList> <CallSheet> <Action>SAVE</Action> <Status>SUCCESS</Status> …. …. </CallSheet> </CallSheetList> • Search for call sheets <CallSheetList> <CallSheet> <Action>SEARCH</Action> <Status>SUCCESS</Status> <CallSheet_Date>1186891200000</CallSheet_Date> <Location>116 Broadway</Location> <Patient_Info><Town>New York</Town></Patient_Info> </CallSheet> </CallSheetList> • View call sheet detail <CallSheetList> <CallSheet> … </CallSheet> <CallSheet> … </CallSheet> … </CallSheetList> • Edit a call sheet <CallSheetList> <CallSheet><Action>SAVE</Action> <Status>SUCCESS</Status> <CallSheet_Number>2</CallSheet_Number> …… …… </CallSheet> </CallSheetList> • Delete call sheets <CallSheetList> <CallSheet> <Action>DELETE</Action> <Status>SUCCESS</Status> <CallSheet_Number>1</CallSheet_Number> </CallSheet> </CallSheetList>

  24. Testing: Data Store (CallSheetFacade.java) • Class under test is very limited in code size due to implementation of EJB. • Due to limited code size, coverage testing was accomplished by using debugger and manually tracking the covered lines. • Developed small test classes to invoke methods in CallSheetFacade.java. Was able to accomplish both black box and white box testing with these acceptance and unit tests.

More Related