The Fantastic 9 CS 6354 Summer 2007 ADS An Ambulance Dispatch System Object Design Document Deliverable 4 CS 6354 Advanced Software Engineering Section 581 Summer 2007 The Fantastic 9 Arturo Saracho Denis Stetsenko Sarthak Dudhara Abdullah Azzouni Russell Smith Anitha John Abhishek Goyal Nate Gardner Sheetal Umeshkumar The Fantastic 9 axs067000 utdallas edu dxs067000 utdallas edu skd051000 utdallas edu ama063100 utdallas edu rss061000 utdallas edu akj041000 utdallas edu axg056100 utdallas edu njg011100 utdallas edu sxu054000 utdallas edu 11120701 10829000 11138921 11152135 11126187 10480080 11139363 10080880 11108292 http www utdallas edu dxs067000 cs6354 The Fantastic 9 CS 6354 Summer 2007 ADS An Ambulance Dispatch System Revision History Version 1 0 Date 7 17 2007 The Fantastic 9 Comments Initial Version Author R Smith http www utdallas edu dxs067000 cs6354 The Fantastic 9 CS 6354 Summer 2007 ADS An Ambulance Dispatch System Object Design Document Deliverable 4 1 Purpose 5 Audience 5 The audience for the ODD includes system architects i e the developers who participate in the system design developers who implement each subsystem and testers 5 1 Introduction 5 1 1 Object design trade offs 5 1 2 Interface documentation guidelines 6 1 2 1 Naming Conventions 6 1 2 2 Files 7 1 2 3 Package and Import Statements 7 1 2 4 Classes and Interfaces 7 1 2 5 Methods 7 1 2 6 Types 7 1 2 7 Variables 8 1 2 8 Loops 8 1 2 9 Conditional 8 1 2 10 Miscellaneous 8 1 3 Definitions acronyms and abbreviations 8 1 4 References 9 2 Packages 9 2 1 File Organization of code 9 2 1 1 CS6354 ADS Main 9 2 1 2 CS6354 ADS Hospital 10 2 1 3 CS6354 ADS Emergency 11 2 1 4 CS6354 ADS Ambulance 12 2 1 5 CS6354 ADS Emergency Caller 13 2 1 6 CS6354 ADS Emergency Case 13 2 1 7 CS6354 ADS Database 14 2 1 8 CS6354 ADS User Interface 14 3 Class Interfaces 15 3 1 Main Sub System 15 3 1 1 ADS Controller 15 3 1 2 Map 16 3 1 3 User 17 3 1 4 Dispatcher 18 3 1 5 Manager 18 3 1 6 Administrator 19 3 1 7 Log 19 3 1 8 Report 19 3 2 Ambulance Sub System 20 The Ambulance Sub System is responsible for all interactions involving Ambulances This sub system consists of the following sub classes 3 2 1 Ambulance List 20 3 2 2 Ambulance 22 The Fantastic 9 http www utdallas edu dxs067000 cs6354 The Fantastic 9 CS 6354 Summer 2007 ADS An Ambulance Dispatch System 3 3 Database Sub System 24 3 3 1 Database 24 3 4 HTML Page Sub System 28 3 4 1 Login HTML Page 28 3 4 2 New Emergency HTML Page 28 3 4 3 Emergency Details HTML Page 29 3 4 4 Active Emergencies HTML Page 29 3 5 Emergency Subsystem 30 3 6 Caller Subsystem 34 3 6 1 Caller 34 3 6 2 Caller List 35 3 7 Hospital Sub System 36 3 7 1 Hospital List 36 3 7 2 Hospital 37 3 8 Case Sub System 38 3 8 1 Case List 38 3 8 2 Case 40 Glossary 43 The Fantastic 9 http www utdallas edu dxs067000 cs6354 The Fantastic 9 CS 6354 Summer 2007 ADS An Ambulance Dispatch System Purpose Object design is documented in the Object Design Document ODD It describes object design trade offs made by developers guidelines they followed for subsystem interfaces the decomposition of subsystems into packages and classes and the class interfaces The ODD is used to exchange interface information among teams and as a reference during testing Audience The audience for the ODD includes system architects i e the developers who participate in the system design developers who implement each subsystem and testers 1 Introduction 1 1 Object design trade offs Buy vs build A decision can be reached by taking into consideration the following points If the software built will provide a competitive advantage by differentiating the company from competitors and if it is practical to build the system given the limited resources for less money and fast enough then it is better to build the system instead of buying it Space vs speed If the software does not meet response time or throughput requirements then more memory can be expended to speed up the software e g caching more redundancy etc If the software does not meet memory space constraints then data can be compressed at the cost of speed Delivery time vs functionality If the development runs behind schedule a project manager can deliver less functionality than specified and deliver on time or deliver the full functionality at a later time Contract software usually puts more emphasis on functionality whereas off the shelf software projects put more emphasis on delivery date Delivery time vs quality If the testing runs behind schedule a project manager can deliver the software on time with known bugs and possibly provide a later patch to fix any serious bugs or to deliver the software later with more bugs fixed Delivery time vs staffing If development runs behind schedule a project manager can add resources to the project in order to increase productivity In most cases this option is only available early in the project Adding resources usually decreases productivity while new personnel is being trained or brought up to date Adding resources will also raise the cost of development The Fantastic 9 http www utdallas edu dxs067000 cs6354 The Fantastic 9 CS 6354 Summer 2007 ADS An Ambulance Dispatch System Files vs databases A file would be chosen incase of voluminous data e g images temporary data e g core file low information density e g archival files history logs A database is chosen in case of concurrent user access access at fine levels of details multiple platforms and multiple applications over the same data 1 2 Interface documentation guidelines After a thorough cost benefit analysis it has been decided that the software will be developed in JAVA The following standards will guide the team in developing the code and interfaces that will facilitate easier integration in later stages of development 1 2 1 Naming Conventions o Names representing packages should be in all lower case o Names representing types must be nouns and written in mixed case starting with upper case o Variable names must be in mixed case starting with lower case o Names representing constants final variables must be all uppercase using underscore to separate words o Names representing methods must be verbs and written in mixed case starting with lower case o Abbreviations and acronyms should not be uppercase when used as name o Private class variables should have underscore suffix o Generic variables should have the same name as their type o All names should be written in English o Variables with a large scope should