User:StarkIndustries~enwiki/FAA SMS

3. Design

The system, as a whole, is designed to identify and mitigate risks at airports by proactively identifying potential hazards and performing necessary actions. It is a sophisticated case management system developed specifically for the airport environment. 3.1 Architecture Design

This section will identify the software and hardware components of the system. It describes how the components interact, and how specifically they communicate. It should, as much as is feasible, be free of implementation details. That comes later. 3.1.1       Structure and Topology

Our Safety Management System is comprised of four major components – case input, a case management system, an analyzer, and output panels. New cases are inputted through various means, including an Android application, web forms, and specialized hazard reporting kiosks, text messages, and radio messages. For those means that require human interpretation (such as text messages and radio messages), those cases will be inputted online using the web forms by a person. Once a case has been submitted, the information will be sent to the case management system. The CMS comprises a case manager interacting with the other components, and a database storing all the cases. Also in the case management system is a policy manager which is responsible for looking up appropriate policies in a database, depending on the type of incident reported. The CMS sole purpose is to provide relevant case information to the analyzer and to the output panels.

The analyzer is responsible for analyzing new and old cases and creating statistics and recommendations. It looks at past cases for patters, and to determine the appropriate actions to take. The statistics and recommendations it generates are passed on to the output panels so the people interacting with the system can have a better understanding of the current case. The analyzer interacts directly with the output panels and the CMS.

The analyzer will also be able to do a self-test on the system to determine its overall safeness. It will do so by looking at recent cases, how fast cases are solved, and other possible issues at the airport.

Finally, the output panels are responsible for providing pertinent information to users of the system. Users of the system can be accountable executives, maintenance crew members, or operations personnel. Depending on what type of user they are, they will be presented with a list of current cases. When a case is chosen, details about the case (including statistics) will be shown. Depending on the user, the case may be editable. If changed or edited, the case is resubmitted back to the CMS and the analyzer will run on the new data. The output panels interact directly with the CMS and the analyzer.

There is one auxiliary component in the system. Certain cases will require that Notice to Airmen (NOTAM) be generated and sent out. It is nearly an automated system, except a user will have to directly tell the system to generate the NOTAM. When a NOTAM is generated, the analyzer is notified to ensure the new notice is taken into account when determining the safeness of the system. 3.1.2       Hardware Required

The hardware necessary for this system is hard to determine. In the least, it requires a central server to collect and process the cases. Input to the system is done mainly from existing devices, but there is a requirement for a person to interpret certain input means (such as a radio and text). As well, specialized reporting kiosks can be built. Output will be done through existing computers and displays.

This portion is currently being worked on by the team. We are setting up meetings with safety personnel at airports to determine what is currently in place, and what more would be needed to implement the system. 3.1.3       Software

The major classes in our design are outlined below.

Figure 0: Outline Panel is displayed on left; Case Panel displayed on right.

// The outline panel has a list of current cases that the user requested. The full case is not displayed, only an outline. If the user wishes to view a certain case, they can just click on it. In essence, the case outlines are large information-filled buttons. Outlines will differ in appearance based on how important they are.

OutlinePanel -list outlines -CaseManager cm	-Analyzer analyzer

// GUI components as in figure, screen on left

// Called by a case outline button being clicked // Potential wait as case manager grabs the case +loadCase(CaseID case) cm.getCase(CaseID, this) // Sent by case manager when a case has been retrieved +msgHereIsCase(Case case) CasePanel cp = new CasePanel(case) cp.show currentGUI.hide

// If another panel completes a case, this will remove it	+msgCaseCompleted(caseID) if outline exists in outlines with outline.caseID==caseID remove outline

// Whenever a new case is submitted or a case is changed +msgHereIsCaseOutline(CaseOutline outline) if exist o in outlines such o.caseID==outline.caseID remove(o) outlines.add(outline)

// A case panel is responsible for showing the current case, any policies associated with it, similar cases, suggested actions from the past, and statistics associated with that type of case

CasePanel // The case being displayed -Case mainCase -Policy policy

// Determines what actions the user is allowed to take String permissions

// Used to pull data about the case and other cases -CaseManager cm

// Similar cases, can be clicked to pull them up	-list referenceCases

// Graph/charts/stats pulled from analyzer -list statistics -Analyzer analyzer

// Similar actions used in the past on this case type -list pastActions

// Object used for products notice to airmen Notam notam // GUI components as in figure, screen on right

+CasePanel(Case mainCase) this.mainCase = mainCase if(mainCase.hasPolicy) policy = db.getPolicy(mainCase.type) analyzer.getAnalysis(maincase.CaseID) pastActions = db.getPastActions(mainCase.type) gui.build

// Called when the user makes changes and they are submitted +updateCase cm.updateCase(Case)

// Called when user enters info and chooses to produce notam +produceNotam(Case case) Notam.produceNotam(case)

// Sent from analyzer when info is ready +hereIsAnalysis(list analysis) Statistics = analysis

// Panels for specific people will display different cases, and will have different permissions with respect to editing cases, sending NOTAMs, and viewing certain details of the case ExecutivePanel extends OutlinePanel	// Increased editing abilities MaintenancePanel extends OutlinePanel	// Basic editing abilities OtherPanel extends OutlinePanel		// Read-only

Definition of policies and procedures regarding safety Policies and procedures are organizational mandates reflecting how senior management wants operations to be conducted. A clear definition is therefore essential to provide operational personnel clear guidance on the operational behavior the organization expects from personnel in day-to-day operations. These same policies and procedures offer the SMS a framework and guidance of how the organization is to address hazards, risks and mitigations. Policies and procedures include the following four components: Standard Operating Procedures (SOP) Emergency Response Plan (ERP) Acceptable Levels of Safety (ALoS) Documentation of the SMS (SMSM)

By accessing the policy, practices and procedures, the SMS is able to get the following information essential to performing the function of the SMS: - Acceptable and unacceptable behaviors within the operating environment. allowing for the identification, classification and catigorization of hazards and potential risks. - Steps and procedures needed to address hazards and risks (mitigation steps) - Identification of Accountable parties to be notified and consulted with in addressing the hazard. - Identification of Key Personnel responsible for exercising the mitigation steps.

The organization's Safety Policy will be stored in the PolicyDatabase which will be accessed by the SMS using the Policy Manager. The PolicyDatabase will cover the following functions involved in the operation of an aerodrome:

1. Operational management

1.1 Movement area access control a) Air	b) Land c) Sea 1.2 Aerodrome emergency planning	a) Emergency procedures manual b) Emergency simulation practices 1.3 Rescue and fire fighting	a) Capability 1) Equipment		2) Foam/water/dry powder discharge rate b) Facility maintenance	c) Staff training and experience d) Equipment mobilization plan	e) Reduction of capability (notice) f) Water hydrant system 1.4 Movement area inspection and maintenance	a) Aerodrome manual b) Inspection forms	c) Maintenance 1.5 Visual aids maintenance a) Inspections	b) Schedule 1.6 Construction management a) Control of works	b) Site management 1.7 Apron safety management, including vehicle traffic a) Rules and regulation for airside operations	b) Airside management 1) Airside vehicle management		2) Airside vehicle licence 3) Vehicle examination		4) Safety specification 5) Aircraft servicing coordination	c) Equipment parking d) Apron discipline	e) Push-back operations f) Traffic signs and markings	g) Stand allocation h) Aircraft damage control	i) Fuel spillage control j) Vehicle and equipment damage control	k) Apron safety checklists including ramp activity audit l) Contracted and subcontracted activities 1.8 Wildlife hazard management	a) Bird control management b) Observation	c) Bird strike report management 1.9 Obstacle control a) Airport boundary	b) Outside the airport c) Runway strip	d) Regulation and survey e) Approval of building construction under the flight path 1.10 Disabled aircraft removal	a) Equipment compatible with aircraft type b) Maintenance for readiness	c) Deployment scheme d) Establishment of outsourcing procedures/contact 1.11 Dangerous goods handling	a) Limitation of dangerous goods on aircraft b) Storage and loading	c) Establishment of training programmes d) Acceptance of dangerous goods by operators	e) Emergency response guidance for aircraft incidents involving dangerous goods 1.12 Low visibility and adverse weather operations a) Procedures	b) Coordination with air traffic services c) Responsibility of organizations involved 1.13 Radio navigation aids installations and maintenance	a) NOTAMS

2. Aerodrome management

2.1 Slots negotiation and allocation 2.2 Flight dispatch 2.3 Follow-me guidance and marshalling 2.4 Movement area management and stand allocation 2.5 Low visibility operations CAT II and CAT III 2.6 Control of traffic rules and licensing regulations 2.7 Cleaning, waste removal and pest control 3. Passenger/terminal building management 3.1 Management of passengers, baggage flow and facilities 3.2 Passengers and public information 3.3 VIP and CIP assistance 3.4 Left luggage 3.5 Porter assistance 3.6 Trolley management 3.7 Cleaning and pest control

4. Air traffic and aeronautical information and communications services

4.1 Air traffic control (aerodrome control under low visibility operations) 4.2 Flight information and alerting services 4.3 Aeronautical information services (international NOTAM office and pre-flight information service) 4.4 Aeronautical telecommunications services

5. Safety and security management

5.1 Implementation and monitoring of the SMS a) Safety manager	b) Hazard identification and assessment of the consequences c) Risks assessment, control and mitigation	d) Safety assurance e) Safety action groups	f) Safety management systems manual (SMSM) 5.2 Implementation and monitoring of the security programme 5.3 Implementation and monitoring of the aerodrome emergency plan (AEP) - Changes in an organization's policies, processes or procedures are potential sources of hazards. As a result, any changes in any of these areas should initiate an SMS evaluation of the impact of the change on the organization's overall level of safety. class Policy int policyID   //unique identifier string policyName // During data analysis, the system will attempt to assign a policy to the case, when applicable string caseTypeApplicableTo // A policy is a list of actions to take list actions

Data Analysis & Database

Description: The Data Analysis system is responsible for calculation statistics and data trends for the Safety Management System. Our end users would then use this information to make future corrective actions using given information.

For example, every time a hazard for foreign object debris (FOD) is reported, it will be saved in the database with a timestamp and description. The Data Analysis system will then store all FOD instances and store this data into a statistics class. The statistical data is then passed to the OutputGUI at request and is then displayed as a line graph showing the relationship between number of occurrences and time of year.

enum TYPE{ maintenance, runway_incursion, fod, // foreign obj debris ... etc. }; struct Case{// safety hazard entry TYPE type, bool wasAnalyzed, String description, Date date Stats stats }; struct Stats{ Type caseType List cases String graphTitle }; struct StatCase{ Time date CaseID id }

public class DataAnalyzer{ Graph maintTimeGraph; Graph fodGraph; Graph incursionGraph;

// Data Analysis Incoming Messages // msg sent from Case Manager void msgNewCase(Case case){ case = timeAnalysis(case); caseManager.updatedCase(case); } // msg sent from OutputGUI void msgGetAnalysis(CaseID id){ Case case = caseManager.getCase(id); // populate case.stats with pertinent info cast.stats = getStats(case); msgHereIsAnalysis(case.stats); }

Stats getStats(Case case){ swith(case.type){ case maintenance: return maintTimeGraph.stats;

case runway_incursion: return incursionGraph.stats;

case fod: return fodGraph.stats;

default: println(“Error in DataAnalysis: Stats not found for unknown 			type!”); return null; } }

timeAnalysis(Case c){ switch(c.type){ case maintenance: maintTimeGraph.add(c.type, c.caseID, c.date); break;

case runway_incursion: incursionGraph.add(c.type, c.caseID, c.date); break;

case fod: fodGraph.add(c.type, c.caseID, c.date);

default: println(“Error in DataAnalysis: Unknown case type found!”); break; } } }

public class Graph{ Stats stats;

public Graph(Type type, String title){ stats.castType = type; stats.graphTitle = title; };	public add(Type type, CaseID id, Time date){ if(stats.type != type){ pritnln(“ERROR!”); }else{ StatCase sc = new StatCase; sc.date = date; sc.id = id; stats.cases.add(sc); } } public stats{ return stats; } }

=
========================== Maintenance Time Graph (Example Graph) Frequency of Maintenance Hazard Entries

=
========================== 10 - 09 - 08 -                           || 07 -                       ||   || 06 -                       ||   || 05 -                       ||   || 04 -   ||             ||   ||   || 03 -   ||   ||   ||   ||   ||   || 02 -   ||   ||   ||   ||   ||   || 01 -   ||   ||   ||   ||   ||   || 00 ---     Jan/ Feb/ Mar/ Apr/ May/ Jun/

Case The case contains the data pertaining to a report that is entered into our system. It is handled by all parts of the system, so it must contain all of the information necessary for input, output, and the analysis in between.

class Case Data: int caseID //unique identifier int userSeverity, userLikelihood //the severity and likelihood as described by user from input int systemSeverity, systemLikelihood//the severity and likelihood as calculated by the system in the analyzer int userPriority, systemInitialPriority, systemPriorityAfter string problemDescription bool handled //true if case has been taken care of string aixm CaseOutline outline // If a policy exists for the specific type of case, it will be loaded in. If not, the policy will remain null. MyPolicy policy Date dateReported // Any hazard, accident, incident will have a type associated with it (or none). This type is used to find the appropriate policy, and is used to determine who should see this particular case. Examples include: birdStrike, fuelSpillage, apronNearMiss, wakeTurbulence, FOD, runwayIncursion, managementChange, auditResponse, planeHit. string type //can be used to help figure out if cases are similar enum cause{humanCaused, animalCaused, environmental, structural, actOfNature, communicationError, equipmentMalfunction etc.} enum objectAffected{engine, fuel system, wheels, lighting, human, etc} enum location{runway, taxiway, plane, helicopter, etc.}

class MyPolicy int policyID list checklist

class ActionItem int checklistIndex String action bool completed //true if the action has been taken

// Used in the output GUI when a list of cases are shown // Shows the gist of the case, without too much data class CaseOutline string description string type int priority

Methods: calculateUserPriority{ //calculate userPriority using userSeverity and userLikelihood } calculateInitialSystemPriority{ //calculate systemInitialPriority using systemSeverity, systemPriority and userPriority } calculateSystemPriorityAfter{ //calculate systemPriorityAfter after the problem has been mitigated } setPolicy(Policy p){ MyPolicy mp		int index = 0 for each action in p.actions{ //create the action checklist from the policy by creating an ActionItem for each policy action and adding it to the checklist ActionItem ai = ActionItem(action, index) checklist.add(ai) index++ } } //add an action to the checklist of things to do to take care of the case addAction(string actionDescription){ ActionItem action = ActionItem(actionDescription, checklist.size) checklist.add(action) } createAIXM{ //creates the aixm string to format the case information according to the AIXM XML schema //we want our case information in this format because it is the standard format for airport data, so it would be easier to give case information to other groups, such as the FAA, which would be necessary in the case of an incident } completeAction(int actionIndex){ //set a policy action as completed checklist[actionIndex].done = true }

//setters and getters setType(string myType) string getType setOutline CaseOutline getOutline setComments(string comments) string getAIXM

Case Manager

The "CaseManager" class is a central pillar to this project. This class is the interface through which the rest of the components access the safety hazard and risk cases within the active and archived databases. This class will use the Agent methodology so we can create queues of all the requests to add/get information from the database. The CaseManager will have a utility class that performs the actual database accessing - this is the "SMSDatabase" class. The CaseManager will have four message methods that other components will use to access the database: msgAddCase(INFO) where INFO is the information to be added to a new Case msgUpdateCase(Case updatedCase) where updatedCase is what it's name implies, the ID of the case to be updated msgGetCase(int caseID, OutputPanel theClient) where caseID is the reference to what case we want, and theClient is the component submitting the request "theClient" will generally be passed by the calling function as a self-reference (ie, "this") msgRemoveCase(int caseID) where caseID is what it's name implies, the ID of the case to be removed only managers and executives will have access to this message

As requests are submitted (in message form), the pertinent data will be placed into its respective FIFO queue which is stored as private List variables. The agent's scheduler checks these and performs operations based on a set priority order:

1) Get Case   	2)  Add Case 3) Update Case   	4)  Remove Case 5) Move To Archive If the queue(s) are not empty, the methods to perform the respective actions will be called in the above order.

package CaseManger; CLASS - Case Manager inherits Agent{ //DATA class CaseRequest{ int reqCaseID; OutputPanel theRequestor; 	 //where this request is coming from }   private SMSDatabase smsDB; private SMSDatabase archiveDB; private PolicyManager policyManager; private Analyzer theShrink; List AddQueue; 	//List used as a FIFO Queue List UpdateQueue;  //List used as a FIFO Queue List GetQueue;  	 //List used as a FIFO Queue List RemoveQueue;  	 //List used as a FIFO Queue List ArchiveAddQueue;  	 //List used as a FIFO Queue List Clients; //List of clients that will be interacting with the CaseManager HashMap caseLocations; //This map will store Case locations, 1 for smsDB, 2 for archiveDB //The caseID will be the key. //MESSAGES void msgAddCase(INFO){ Case newCase; newCase.INFO = INFO; AddDBQueue.add(newCase); semaphore.acquire; }   void msgUpdateCase(Case updatedCase){ if (updatedCase.completed){ //case complete, move to archive ArchiveAddQueue.add(updatedCase); } else { UpdateQueue.add(updatedCase); }  	 sempahore.acquire; }   void msgGetCase(int caseID, OutputPanel theClient){ CaseRequest req = new CaseRequest; req.reqCaseID = caseID; req.theRequestor = theClient; GetQueue.add(req); semaphore.acquire; }   void msgRemoveCase(int caseID){ //this function can only be called by certain authenticated terminals //   for now, we'll assume only the accountable executive can actually send this message RemoveQueue.add(caseID); semaphore.acquire; }   //SCHEDULER while(...){ if (GetQueue is not empty) GetCase; if (AddQueue is not empty) AddCase; if (UpdateQueue is not empty) UpdateDB; if (RemoveQueue is not empty){ RemoveCase; if (ArchiveAddQueue is not empty) MoveToArchive; //METHODS public CaseManager{ //create casemanager object. //call Initialize if needed. }   private void Initialize{ if this is a new system, intialize DB  		 smsDB = new SMSDatabase("SMS_DB", new Connection(...), "..."); smsDB.createTable; smsDB.populateTable; else if its already existing, initialize DB hashmaps }   public void AddCase{ Case myCase = AddQueue.get;  //get first item in list. if (!myCase.hasPolicy){ policyManager.msgGetPolicy(myCase);  	 //inform policy manager this new case requires policy info }  	 smsDB.addCase(myCase); AddQueue.remove(myCase); 	//add was successful, remove from queue caseLocations.add(myCase.caseID, 1); theShrink.newCase(myCase); BroadcastOutline(myCase.Outline); semaphore.release; }   public void UpdateDB{ Case myCase = UpdateQueue.get; //get first item in list. smsDB.updateCase(myCase); UpdateQueue.remove(myCase);  	 //add was successful, remove from queue BroadcastOutline(myCase.Outline); sempahore.release; }   public void GetCase{ CaseRequest req = GetQueue.get //get first item in list Case myCase; if (caseLocations.get(caseID) == 1) myCase = smsDB.getCase(req.reqCaseID); send req.theRequestor myCase; else if (same == 2){ myCase = archiveDB.getCase(req.reqCaseID); send req.theRequestor myCase } else { send req.theRequestor alert, case not found. }   }    public void MoveToArchive{ Case myCase = ArchiveAddQueue.get; smsDB.delCase(myCase.caseID); archiveDB.addCase(myCase); caseLocations.remove(myCase.caseID); caseLocations.add(myCase.caseID, 2); sempahore.release; }   public void BroadcastOutline(CaseOutline outline){ for each OutputPanel client in Clients{ client.caseOutline(outline); }   }    public void RemoveCase{ int id = RemoveQueue.get; smsDB.delCase(id); RemoveQueue.remove(first); semaphore.release; }   public List getCaseListing{ //query the Database and get a list of all cases. //possibilities may be to allow refinements in query to acquire only specific or desired Case Entries. }   public List getCaseIDListing{ //query the database and get a list of CaseID's   } }

SMSDatabase

This class is a utility class to the “CaseManager.” This is where the actual database interaction will happen. As the requests to get and store information are queued in the CaseManager, it will call commands within this SMSDatabase class to perform the actual operations.

//Be sure to include/import Database API. Design Doc tailored to use of JDBC Driver for Java. package CaseManager.Utilities; CLASS - SMSDatabase{

private String dbName; private Connection con; private String dbms;

public SMSDatabase(String name, Connection connection, String dbMS){ //initialize values of dbName, con, & dbms }   public void createTable{ //create a table in our database for SMS data // *note: will only be called once, during initial setup. }   public void populateTable{ //populates the table with our initial values // *note: will only be called once, during initial setup. }

public int addCase(Case newCase){ if (smsDB.getCaseID(newCase) != -1){ //means the case is not already in the database //add to database }  	 return isSuccess //return true if the operation succeeded }   public boolean updateCase(Case theCase){ //update case within the database //most likely will involve replacing entry. return isSuccess //return true if the operation succeeded }   public Case getCase(int CaseID){ //check connection to database //if good, perform GET command, get case with CaseID Caseid. //if not, reconnect to DB and try again if Case exist in DB,   return Case if Case DNE in DB,   	 return null; }   public int getCaseID(Case theCase){ //search for case within the database return caseid; //return -1 if not found. }   public boolean delCase(int Caseid){ //check to be sure case exists in database. //remove case with Caseid from the database //remove row in database. return isSuccess //return true or false depending on if the operation succeeded. }   public boolean connectDB{ //connect to current Database //used if say, connection is lost return isSuccess //returns true or false depending on if the operation succeeded. }   public boolean connectNewDB(String newdbName, Connection newCon){ //Connect to new database return isSuccess //returns true or false depending on if the operation succeeded. }   public boolean disconnectDB{ //disconnect from current Database. return isSuccess //returns true if operation succeeded successfully. }   }

Policy Manager

The "PolicyManager" class is very similar to the CaseManager class, the only difference being it is a queue into the PolicyDatabase, rather than the SMS case Database. Here is where we can access, update, and remove stored FAA and Airport policies. As with the CaseManager, the PolicyManager designed as an agent so we can build up a Queue of requests and process them efficiently and safely. Most of the time, the Policy Manager will just be handling "GetPolicy" requests, but Managers and Accountable Executives have the ability to update, add, and remove policies.

This dynamic idea allows the airport to adjust and make updates to their policies in real time as management approves and implements policies.

package PolicyManager CLASS -   PolicyManager {

//DATA class PolicyRequest{ int reqID; OutputPanel theRequestor; 	 //where this request is coming from }   CaseManager caseManager; PolicyDatabase PDB; List<Case> findPolicyQueue; List<PolicyRequest> getPolicyQueue; List<Policy> updatePolicyQueue; List removePolicyQueue; //MESSAGES void msgFindPolicyForCase(myCase){ findPolicyQueue.add(myCase) semaphore.acquire; }   void msgGetPolicy(int policyID, OutputPanel client){ PolicyReq req = new PolicyReq(policyID, client); getPolicyQueue.add(policyID); semaphore.acquire; }   //only certain users can access this message - ie, managers / executives void msgUpdatePolicy(Policy updatedPolicy){ updatePolicyQueue.add(updatedPolicy); semaphore.acquire; }   //only certain users can access this message - ie, managers / executives void msgRemovePolicy(int policyID){ updatePolicyQueue.add(updatedPolicy); semaphore.acquire; }

//SCHEDULER while(...){ if (getPolicyQueue is not empty) getPolicy; if (updatePolicyQueue is not empty) updatePolicy; if (removePolicyQueue is not empty) removePolicy; if (findPolicyQueue is not empty) findPolicy; }   //METHODS public PolicyManager{ //CONSTRUCTOR }   private void Initialize{ //INITIALIZE DATABASE ON FIRST RUN }   void findPolicy{ Case myCase = findPolicyQueue.get;   //get the first item in the list //run case through algorithm to decide which policy we should get //algorithm not yet written. //returns int policyID myCase.suggestedPolicy = PDB.getPolicy(policyID); caseManager.msgUpdateCase(myCase); getPolicyQueue.remove(first); semaphore.release; }   void getPolicy{ PolicyRequest req = getPolicyQueue.remove(first); 	 //get and remove first item in list Policy p = PDB.get(req.reqID); if p exists in PDB,   send p to req.theRequestor; else if p DNE in PDB, inform req.theRequestor; semaphore.release; }   void updatePolicy{ Policy upd = getUpdateQueue.remove(first); //get and remove first item in list PDB.delPolicy(upd.policyID);  	//remove old information for this policy PDB.addPolicy(upd); 	//add updated policy to the DB  	 sempahore.release; }   void removePolicy{ int id = removePolicyQueue.remove(first);   //get and remove first item in list PDB.delPolicy(id); semaphore.release; } }

Policy Database

The “PolicyDatabase” class is a utility class for the PolicyManager in the same way the SMSDatabase class is a utility to the CaseManager - it performs the actual database interactions.

//Be sure to include/import Database API. Design Doc tailored to use of JDBC Driver for Java. package PolicyManager.Utilities; CLASS - PolicyDatabase{

private String dbName; private Connection con; private String dbms;

public PolicyDatabase(String name, Connection connection, String dbMS){ //initialize values of dbName, con, & dbms }   public void createTable{ //create a table in our database for SMS data // *note: will only be called once, during initial setup. }   public void populateTable{ //populates the table with our initial values // *note: will only be called once, during initial setup. }

public boolean addPolicy(Policy newPolicy){ //add policy to database return isSuccess }   public boolean updatePolicy(Policy thePolicy){ //update policy within the database //most likely will involve replacing entry. return isSuccess //return true if the operation succeeded }   public Policy getPolicy(int Policyid){ //check connection to database //if good, perform GET command, get case with PolicyID Policyid. //if not, reconnect to DB and try again return Policy }   public boolean delPolicy(int policyid){ //check to be sure policy exists in database. //remove case with Policyid from the database //remove row in database. return isSuccess //return true or false depending on if the operation succeeded. }   public boolean connectDB{ //connect to current Database //used if say, connection is lost return isSuccess //returns true or false depending on if the operation succeeded. }   public boolean connectNewDB(String newdbName, Connection newCon){ //Connect to new database return isSuccess //returns true or false depending on if the operation succeeded. }   public boolean disconnectDB{ //disconnect from current Database. return isSuccess //returns true if operation succeeded successfully. } }

3.2 System Services and Processes

Here you must prove that the designed system will fulfill its requirements. Focus on the users of the system and what services the system is providing them. Before we had capabilities and requirements, now we have specific services that produce the required behavior. 3.2.1   The Functional Use-Cases

A good way to model the services is as use-cases, but this time, the external players must be interacting with components through formal computer protocols and interfaces. These use-cases will be formalized to show the functional interactions with THE SYSTEM. Hazard Reporting (Incomplete) UC-01: Employee Reports Hazard The following case describes how an operations agent conducting the airport's daily self-inspection finds some foreign object debris (FOD) of substantial size and weight at a taxiway-runway intersection adjacent to an uncontrolled ramp, and how the agent uses the SMS to report the hazard. The operations agent documents the FOD, as a potential threat to safety. All pertinent information about the FOD including, picture, description, size, weight, and location are entered into the SMS using the Hazard Reporting System. The SMS system receives the hazard report, analysis the hazard with respect to how it affects the current level of safety. Using the Safety Risk Managment process, the system determines the severity, likelihood and  possible outcomes of that hazard. Numerous risk mitigation strategies based on the airport's safety policy and past FOD incidents are complied. A prioritized list of proposed mitigations is immediately sent to the appropriate accountable executive(s) and responsible personnel as well as the implementation of any automated response to mitigate the hazard. The system disseminates the applicable safety information to tenants who operate in the area to warn them of the FOD hazard, potential risks and mitigation. The system completes the analysis by documenting the processes and determinations in the appropriate databases following the airport's SMS guidelines. A notification of the address and resolution of the reported hazard is returned to the reporting party. Finally, the system adds an entry to the SMS to follow up in two weeks to review the self-inspection and targeted inspection reports to verify whether mitigations are working.

3.2.2   Mockup

Place any screen mockups here. Figure 1 - Mockup of Output Panels Figure 2: Data Analysis Sample Graph 3.2.2   Interaction or Sequence Diagrams

Figure 3: Normative Scenario Interaction Diagram