Delivarable 4 Object Design Document http www utdallas edu mas027000 Object Design Document Introduction 1 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 NOTE This document discusses the object design as per the current status of the implementation phase For more information about the current implementation status and future extensions please refer to deliverable 0 Project Plan 1 1 Object Design trade offs The following are the trade offs found in our ADS 1 1 1 Buy Vs Build Our concept about Buy Vs Build is analogous to this statement If you can get 80 of the functionality you need from a packaged solution then buy it Otherwise build it Of course the system that we have can be divided into modules If we can find some module in the market with most of the functionality that we need included in it then that system can be bought to save time money and human resources When a solution module is bought it provides ready functionality but if the developer doesn t know how it works because its source code will not be available then it is a waste Sometimes when this module is integrated with the rest of the system it might be very hard for it to adapt to the system and so the entire system might have to be changed which would be costlier than expected Therefore based on these requirements in the ADS we can buy modules like 1 Finding the current location of a patient 2 Reporting module 3 Showing the right address map to the ambulance personnel GPS 1 1 2 Guidelines and Convention This sub section describes about Naming Conventions boundary cases exception handling mechanisms 1 1 3 1 Naming Conventions This section is describe in 1 2 subsection in detail 1 1 3 2 Boundary Cases From the UI any text entry field should have a maximum length which indicates a boundary Also from the UI depending on the language we use the numeric fields could also contain alpha characters which could cause all kinds of internal issues Depending on the type of database we use the fields might have a maximum width value We need to make sure there is enough space in each of the fields 1 Delivarable 4 Object Design Document http www utdallas edu mas027000 There are also conceptual boundaries What happens when the injured in an incident report exceeds the of ambulances available or just in general After we ve exceeded the simulated 3 minute and 12 minute marks and sees the errors how does the software behave Does it expire the ticket On a separate note with the current database fields in the different tables it seems quite strange that we appear to throw away the Intersection info and the brief description info The reports database seems out of place with the rest of our system We have an exception dialog but we do not appear to store that information anywhere unless that s what the reports database is used for It does not appear to have the same fields that appear in deliverable3 It contains the report ID date of report author of report and a document with the report information The incident ID We need to make sure it is an unsigned int to make sure it never rolls over and becomes negative There is still yet another boundary at around 2 32 1 for the INT but the only thing we can do about that is throw an exception 1 1 5 Exception Handling Mechanisms The ADS system is dealing with this programming language construct to ensure the fact that normal flow of execution takes place constantly Not only just to synchronize the integrity of the system but our EHM is merely focused about what are the constraints and raising these exceptions in a useful way to deal with any sort of problem or semi predicate problem as listed below a Position Exception This is about the horizontal geographical coordinates HGC namely represented as Longitude Latitude While getting the information of incident this detail is to verify that the ambulance is meant to give service within that HGC Else exception is encountered to illustrate the invalid position for the incident information b No Ambulance Exception This exception is invoked by dispatch method when the class ambulance locator 3 finds no availability of ambulance within the feasible perimeter of dispatch c Invalid User Name Password Exception The user enters the Dispatcher ID and password into the encrypted text fields and clicks on Logon The Dispatcher UI communicates with the User Management subsystem to verify whether the Dispatcher ID already exists and if it does whether the password is correct or not If the Dispatcher ID does not exist or the password is incorrect then an Invalid User Name Password exception is displayed d Overtime Exception This is about the ambulance with a time tracker on the screen to display as to how much time has passed since the incident was created This page refreshes every two seconds to show the latest availability of the ambulances i e dispatched If the time exceeds 11 minutes then an Overtime Exception message pops up 2 Delivarable 4 Object Design Document http www utdallas edu mas027000 e Invalid Data Exception This exception is invoked when any information mismatch to the data type is tried to save in order to create any ticket by a dispatcher 1 2 Interface documentation guidelines Naming conventions make programs more understandable by making them easier to read They can also give information about the function of the identifier for example whether it s a constant package or class which can be helpful in understanding the code This section will give an insight about the Naming Convention They are described individually in the table Identifier Type Packages Classes Interfaces Methods Variables Rules for Naming The prefix of a unique package name is always written in capital and all lowercase ASCII letters except abbreviations like UI is User Interface so as not to make lengthy package name We ve not used any top level domain names currently com edu gov mil net org or one of the English two letter codes identifying countries as specified in ISO Standard 3166 1981 Class names should be nouns in mixed case with the first letter of each internal word capitalized We kept our class names simple and descriptive Nonetheless we used whole words and avoided acronyms and abbreviations as far as possible unless the abbreviation