U
NIVERSITY OF
L
ISBON
Faculty of Sciences
Department of Informatics
HAZARD LOGGING AND MANAGEMENT SYSTEM
Maria João Roque Barbado Leal
PUBLIC
MASTERS IN INFORMATICS ENGINEERING
Specialization in Information Systems
2010
U
NIVERSITY OF
L
ISBON
Faculty of Sciences
Department of Informatics
HAZARD LOGGING AND MANAGEMENT SYSTEM
Maria João Roque Barbado Leal
PROJECT
Project oriented by Prof. Doctor Pedro Alexandre de Mourão Antunes and by Eng. Paula Luisa Costa Teixeira Santos
MASTERS IN INFORMATICS ENGINEERING
Specialization in Information Systems
2010
Resumo
No âmbito do sistema de gestão da segurança (SMS), existente nos serviços de con-trolo de tráfego aéreo, uma variedade de perigos, para os serviços prestados, são identi-ficados e classiidenti-ficados de acordo com seu potencial impacto. Estes perigos precisam ser seguidos e devem ser geridos de uma forma clara e eficiente, desde a fase de concepção do sistema, ou de qualquer alteração importante feita nos sistemas em operação, até à sua retirada de serviço. A principal missão da NAV Portugal é proporcionar serviços de controlo de tráfego aéreo nas Regiões de Informação de Voo (RIV) de responsabilidade Portuguesa (Lisboa e Santa Maria), assegurando que as normas nacionais e internacionais sejam cumpridas nas melhores condições de segurança, optimizando capacidades, e enfa-tizando a eficiência, não deixando de lado as preocupações ambientais.
Na NAV Portugal este processo ainda é baseado papel e carece de um sistema central onde toda a informação pode ser armazenada de forma consistente, actualizada e acedida. Este projecto de nove meses teve como principal objectivo analisar e desenvolver uma solução para registar perigos e toda a informação associada, tal como acções de miti-gação, a frequência aceitável de ocorrências, as próprias ocorrências e os seus impactos. O sistema de registro e gestão de perigos foi desenvolvido com a supervisão da Eng. Paula Santos, chefe da área SISQUA (Sistemas de Gestão de Qualidade e Safety). SISQUA é uma das quatro áreas que compõem o Departamento de Sistemas e Tecnologia da Infor-mação (DSTI). DSTI representa a empresa em assuntos nacionais e internacionais rela-cionadas com a evolução do ATM. Devido ao papel crítico desempenhado pelos presta-dores de serviços de controlo de tráfego aéreo no transporte diário de milhares de pes-soas, a NAV Portugal tem implementado um extenso Sistema de Gestão Ambiental e de Qualidade, em conformidade com os requisitos da NP EN ISO 9001:2008 e NP EN ISO 14001:2004 (+ Emenda 1: 2006). Este sistema de gestão abrange a prestação de serviços de navegação aérea em geral e outros serviços relacionados, tais como Gestão de Informações Aeronáuticas (AIM), das Comunicações, Navegação e Vigilância (CNS), treinamento e serviços de desenvolvimento de sistemas de ATM. Esta implementação garante, não só, a uniformidade de procedimentos dentro da organização, mas também a conformidade com os procedimentos definidos e transparência exigidos pelos auditores externos.
teve também que incluir módulos para gestão de utilizadores, backup de dados e login para garantir o cumprimento do objectivo principal do projecto.
Em termos de desenvolvimento de software, a solução teve que ser desenvolvido de acordo com, não apenas, os requisitos funcionais, mas também os requisitos não-funcionais, tais como, uma boa capacidade de integração com outros sistemas e utilização de tecnolo-gias de código aberto, não proprietárias, estáveis, que garantam a disponibilidade de dados e a sua facilidade de manutenção.
Juntamente com a produção de um sistema de gestão e registo de perigos, este pro-jecto teve como objectivo apresentar toda a documentação necessária para garantir que as decisões foram documentadas, justificadas e avaliadas. Entre os documentos exigidos enfatiza-se especialmente o documento de especificações do sistema (DES), o Plano de Gestão de Testes (TMP), o documento dos testes de aceitação (ATD), o documento sobre a arquitectura do sistema(SAS) e o manual do utilizador(OH).
Durante a análise de requisitos foi necessário uma representação conceptual dos conceitos que envolviam o projecto. O modelo entidade-relação (ERM) foi o modelo escolhido pela sua abordagem top-down. Este modelo foi evoluiu durante a fase de recolha de requisitos e mostrou ser a mais importante e inovadora realização do projecto.
Após as fases de levantamento de requisitos e definição do modelo de dados, foi essencial definir abstractamente a estrutura do sistema. A arquitectura do sistema é uma represen-tação conceptual, baseado na caprepresen-tação de diferentes elementos que descrevem a estrutura do sistema. Uma das principais decisões de arquitectura foi a utilização de serviços Web incorporando o padrão Model View Controller. Esta abordagem, além de todas as vanta-gens inerentes, também oferece a cobertura de alguns dos requisitos não-funcionais como, interoperabilidade ou acesso à Internet para diversos utilizadores com diferentes tipos de permissões no sistema.
A fim de atingir os requisitos e arquitectura definidos uma variedade de tecnologias foram escolhidas, como o GWT e SmartGWT para desenvolvimento da camada de interacção com o utilizador ou o Hibernate para mapeamento da base de dados. Esta decisão teve em conta que as tecnologias utilizadas tinham de ser livre, permitir a evolução do projecto e garantir a fiabilidade e disponibilidade dos dados.
Actividades de validação e verificação de produto foram realizadas durante todo o ciclo de vida do projecto, da validação dos requisitos até a testes de aceitação do produto, para atingir, tão cedo, como possível a identificação de problemas, ou insuficiências, reduzindo assim o impacto de mudanças provocadas pela necessidade de correcções, ou adaptações. Durante os nove meses de estágio foram cumpridos todos os objectivos do projecto, pondo em prática os conhecimentos adquiridos na universidade com um alto grau de independên-cia e estar em contacto com novas tecnologias, como o GWT e SmartGWT, trabalhar
numa arquitectura orientada a serviços e integrar um ambiente bem estruturado e de as-segurada qualidade profissional. O projecto também deu a oportunidade de estudar e analisar uma área estimulante, que é ainda muito baseados em documentos em papel e em que a informática pode ter um impacto considerável.
A maior principal do projecto foi a realização de todas as metas no prazo estipulado, dev-ido à sua complexidade e ao facto de que não existirem projectos semelhantes disponíveis para comparar e obter informações.
Abstract
Under the air traffic services safety management system (SMS) a variety of hazards, to the provided services, are identified and classified according to their potential impact. These hazards need to be followed and should be managed in a clear and efficient way, from a new system design phase, or any important change made in the systems in opera-tion, until their withdrawal from service. In NAV Portugal this process is still paper based and lacks a central system where all the information can be consistently stored, updated and accessed.
This project aimed to analyze and develop a solution to register hazards and associated information, such as mitigation actions, acceptable frequency of occurrence, recorded oc-currences and their impacts. This solution must, at any time, report on what dangers are associated with a given system, how they may be mitigated and if the hazards frequency of occurrence is within the defined range. Also, the solution had to include a user manage-ment, login and data backup modules to ensure the projects main goal accomplishment. In terms of software development, the solution had to be developed according to, not only, functional requirements, but also to non-functional requirements, such as, a good capa-bility of integration with other systems and use stable available open source technologies, that ensured data reliability, availability and maintainability.
Alongside the production of an hazard management and logging system, this project aimed to produce the required documentation that ensured all decisions were documented, justified and evaluated. Among the required documentation special emphasis had to be put on the production of the System Specification Document (DES), on the Test Manage-ment Plan (TMP), on the Acceptance Tests DocuManage-ment (ATD), on the System Architecture Specification (SAS) and on Operating Handbook (OH).
This project has met all its initial goals arousing international interest.
Contents
List of Figures xiv
List of Tables xvii
1 Introduction 1 1.1 Context . . . 1 1.2 Goals . . . 1 1.3 Document organization . . . 2 2 Project 3 2.1 Organization . . . 3 2.2 Organizational Structure . . . 4
2.3 Organizational Quality Management . . . 6
2.4 Development Methodology . . . 7
2.5 Tasks . . . 8
3 Context Study 11 3.1 Safety . . . 12
3.2 Hazards and Occurrences . . . 13
3.3 Risk Classification . . . 16
3.4 Safety Objective . . . 16
3.4.1 Safety Objectives Quantification . . . 17
3.4.2 Qualitative Model . . . 17 3.5 Safety Management . . . 20 3.6 Computational Support . . . 22 3.7 Hazard Logging . . . 23 4 Project Development 25 4.1 Project Requirements . . . 25 4.1.1 Users . . . 26 4.1.2 Functional Requirements . . . 26 4.1.3 Non-Functional Requirements . . . 27 ix
4.2.2 Integrity Rules . . . 30 4.2.3 Relational Model . . . 31 4.2.4 Database Model . . . 33 4.3 Architecture . . . 34 4.3.1 Web services . . . 34 4.3.2 REST . . . 36
4.3.3 Model View Controller Pattern . . . 38
4.4 Technologies . . . 40
4.4.1 Google Web Toolkit . . . 41
4.4.2 Smart GWT and Smart Client . . . 41
4.4.3 JSON . . . 42
4.4.4 Hibernate . . . 42
4.4.5 Session Management and Cookies . . . 43
4.4.6 User Privacy and Security . . . 44
4.5 Tests . . . 44
4.5.1 Unit Tests . . . 45
4.5.2 Integration Tests . . . 45
4.5.3 Acceptance Tests . . . 45
4.5.4 Test Approval Criteria . . . 50
5 Implementation 53 5.1 Package Organization . . . 53 5.2 Web Services . . . 55 5.2.1 User Management . . . 56 5.2.2 Data Management . . . 58 5.2.3 Log Management . . . 63 6 Results 65 Glossary 70 x
List of Figures
2.1 Flight information region of Portuguese Responsibility[12] . . . 3
2.2 Business Areas[12] . . . 4
2.3 Company’s Organogram. [12] . . . 5
2.4 Diagram illustrating the Unified Process flow. . . 7
2.5 Project Activities. . . 9
2.6 Project Timing . . . 10
3.1 Accident penetrating all defensive layers[24] . . . 13
3.2 Example - Hazard’s Bow-Tie Diagram[20] . . . 14
3.3 Quantitative Model Hazard Safety Objective Example . . . 19
3.4 FHA report table example . . . 24
4.1 Example of a formal use case description. . . 27
4.2 Early Entity-Relationship Model . . . 29
4.3 Final Database Model . . . 33
4.4 Platforms and devices . . . 35
4.5 Independent Data Layer . . . 36
4.6 Model View Controller diagram.[30] . . . 39
4.7 Technology Stack Diagram . . . 40
4.8 Test Model . . . 46
4.9 User Management Tests . . . 47
4.10 Hazard Environment Management Tests . . . 48
4.11 Hazard Management Tests . . . 49
4.12 Example - Add Cause Acceptance Test Specification . . . 50
5.1 Hazard Management Tests . . . 54
5.2 Quantitative Model Hazard Safety Objective Example . . . 55
5.3 Login Screen . . . 56
5.4 Login Activity Diagram . . . 57
5.5 Add User Screen . . . 57
5.6 Add Effect Screen . . . 58
5.7 Add record activity diagram example . . . 59
5.8 View Record Content Screen . . . 60 xiii
5.11 Update Record Activity Diagram Example . . . 62 5.12 Change System State Screen . . . 63
List of Tables
3.1 Severity Classification Scheme in ATM [15] . . . 15
3.2 Severity Classification Scheme for ATM specific occurrences [16] . . . . 15
3.3 Example - Risk Classification Scheme[18] . . . 16
3.4 Specification of National Regulatory RCS[35] . . . 18
3.5 Specification of ATMSP RCS[35] . . . 18
3.6 ATMSP RCS . . . 18
3.7 Requirements for Safety Management Systems[21] . . . 21
3.8 Comparative benefits of a positive safety culture[17] . . . 22
Chapter 1
Introduction
This chapter provides an overview of the Hazard Logging and Management System de-veloped at NAV Portugal, the Portuguese Air Traffic Management Service Provider, as part of my nine months internship. This chapter shortly describes the project’s context and goals. These goals were fully achieved during the internship, having received in-ternational recognition. The project as well as a successful personal integration in the work environment, working team and company’s development methods. As this project is subject to confidentiality some parts of the final report are not included in this public version.
1.1
Context
The air traffic services Safety Management System (SMS) defines a variety of hazards and classifies them according to their potential impact. These hazards need to be followed by the safety and should be managed in a clear and efficient way, throughout all of the service life cycle. In NAV Portugal this process is still paper based and lacks a central repository where all the information can be consistently stored, updated and accessed.
1.2
Goals
This project aimed to analyze and develop a solution to register hazards and all of the associated information, such as mitigation actions, acceptable frequency of occurrence, recorded occurrences and their impacts. This solution must be able to, at any time, report on what dangers are associated with a given system, how they may be mitigated, and if the hazards frequency of occurrence is within the defined range. Also, the solution had to include user management and data backup modules.
In terms of software development, the solution had to be developed according to func-tional requirements, but also to non-funcfunc-tional requirements, including integration with other systems and adoption of stable open source technologies, ensuring data reliability,
availability and maintainability.
Alongside the production of an hazard management and logging system, this project aimed to comply with strict rules requiring that all decisions are documented, justified and evaluated. Among the required documentation, special emphasis had to be put on the production of the System Specification Document (DES), the Test Management Plan (TMP), the Acceptance Tests Document (ATD), the System Architecture Specification (SAS) and the Operating Handbook (OH).
1.3
Document organization
This document describes in detail the work performed during the nine months internship at NAV Portugal and is structured as follows.
The following chapter overviews the hosting institution in terms of business areas, struc-ture and quality management principles. It also, explains how the project is inserted in the organizational context, the adopted development methodologies and the task schedule. The third chapter presents the problem and its context, the necessary background informa-tion and the main concepts used through the project, giving a vital and clear understanding of the developed work. Safety, hazards, occurrences and hazard logs are key notions that will be defined it this chapter.
The project development is presented in the fourth chapter, showing and explaining the outcomes of the requirements gathering and specification phases, data modeling, archi-tecture specification, tests specification and chosen technologies.
The ensuing chapter describes the final implementation decisions, encountered difficul-ties and the application’s results. Examples of the main functionalidifficul-ties are also given. The last chapter discusses the project’s outcomes in terms of personal and organizational gains. This chapter, also discusses the projects future prospectives and possible evolution.
Chapter 2
Project
2.1
Organization
The NAV Portugal’s main mission is to provide air traffic services in the Flight Informa-tion Regions (FIR) under Portuguese responsibility (Lisbon and Santa Maria), ensuring that national and international regulations are complied with in the best safety conditions, optimizing capacities, and emphasizing efficiency while not neglecting environmental concerns. The company carries out its work on mainland Portugal and in the autonomous regions of Azores and Madeira.
Figure 2.1: Flight information region of Portuguese Responsibility[12]
The company’s head offices are situated next to Lisbon Airport, as are the Lisbon Air Traffic Control Center and the Training Center. The Oceanic Control Center is located on the island of Santa Maria in the Azores autonomous region. In additional to these two important centers, NAV Portugal has other infrastructures operating in the control towers of Lisbon, Porto, Faro, Funchal, Porto Santo, Santa Maria, Ponta Delgada, Horta, and
Flores airports and, also, provides air traffic services to Cascais aerodrome.
To fully carry out its air traffic control mission, NAV Portugal operates a considerable amount of equipment and technical installations (radar, radio and communications stations).[7]. NAV Portugal, as the national Air Navigation service provider participates, represent-ing in some cases the Portuguese State, in organizations related to civil aviation, such as ICAO (International Civil Aviation Organization), United Nations Organization for Civil Aviation, worldwide and EUROCONTROL (European Organization for the Safety of Air Navigation), whose membership includes almost all the European states. NAV Portugal is also a member of CANSO (Civil Air Navigation Services Organization).
Figure 2.2: Business Areas[12]
2.2
Organizational Structure
To accomplish its mission, NAV Portugal has a welldefined organizational structure, shown in Fig 2.2 and 2.3. With relevance to this work, we highlight the following units:
• DOPLIS e DOPATL - Ensure the Air Navigation Services provision, respectively, in the Flight Information Region of Lisbon and the Flight Information Region of Santa Maria.
Chapter 2. Project 5
Figure 2.3: Company’s Organogram. [12]
• DSEGOP - Responsible for Operating Security System, Procedures, Operational and Maintenance Routines, Traffic and Technical Indicators and Aeronautical In-formation Provision Service.
• DSTI e DETPRO – Ensure technical evolution, strategic investments and opera-tional, or technical developments in the ATM and CNS areas, respectively.
• DREL - Human resources management, guaranteeing the necessary resource con-ditions and availability to pursue the company’s goals.
• DAFIN - Responsible for the economical and financial areas.
• DGQUA - Quality Management System promotion and management, covering also the environmental aspects.
• GABJUR, GABDES, GABCIM, COGEST e FORMA – Ensure advice to the Board and other organs of the company, particularly in the areas of legal issues inherent to the business, the definition of strategy and external positioning, the image diffusion, consolidation of enterprise culture, activity monitoring and training.
The Hazard Logging and Management System was developed with supervision of Eng. Paula Santos, head of SISQUA area. SISQUA is one of four areas that compose the De-partment of Systems and Information Technology (DSTI). DSTI represents the company in national and international matters related with developments in ATM. DSTI, also con-ducts technical studies and monitors the operations of Air Traffic Management Support Systems in compliance with national and international standards. Also, DSTI develops ATM systems for the ACC (Area Control Center) and control towers.
The department is divided in several areas, including SISINT, SISPRO, SISLOG, SISQUA. SISINT is responsible for identifying operational requirements, producing functional and test specifications and performing validation/acceptance tests for the ATM systems. SIS-PRO is responsible for the systems architecture and its development. SISLOG deals with logistical issues, like the process of acquisition of hardware. The current project is inte-grated in the SISQUA (Quality and Safety Management Systems) area, which is responsi-ble for selecting and developing procedures in accordance with national and international standards. SISQUA also assists and monitors the implementation of procedures defined by the Quality Management System, and assists and monitors the application of Safety standards in the development of ATM systems.
This project also included the participation of members of NASO and SEGNA, areas within DSEGOP for requirement gathering; and members of EUROCONTROL for haz-ard logging working experience information exchange.
2.3
Organizational Quality Management
Due to the critical role played by Air Traffic Control Service Providers in the transporta-tion of thousands of people every day, NAV Portugal has implemented an extensive Qual-ity and Environmental Management System, in accordance with the requirements of NP EN ISO 9001:2008 and NP EN ISO 14001:2004 (+ Amendment 1: 2006). This man-agement system covers the air navigation services provision in general and other related services, such as Aeronautical Information Management (AIM), Communications, Navi-gation and Surveillance (CNS), Training and ATM Systems development services. This implementation ensures, not only, the uniformity of procedures within the organi-zation but also the conformance with defined procedures and transparency required by external auditors.[12]
In this context, the NAV Portugal’s activity is characterized by a set of business pro-cesses, called operating procedures and a set of management and support processes. The operational processes go from marketing and sales to ATM service provision. The support processes go from human resource management to external relations management. This project adopted the operational process for System Development Service Provision (POP 20) and its related procedures. For each POP 20 procedure, there is defined set of documentation needed; and each document has a template, which has the respective completion instructions. This approach makes all documents more homogeneous and in conformity with standards. All documents are reviewed by several people from different areas, who are related with the project, including the quality department. The produced documents, if necessary, are updated to include comments from the reviewers. In order
Chapter 2. Project 7
to be approved, all of the produced documentation has to be distributed and reviewed by members of SISINT, to verify requirements and test specifications, members of NASO and SEGNA, to verify the system functional and non-functional requirements, and by members of SISQUA, to verify consistency, completion and traceability.
2.4
Development Methodology
As stated in the previous section, the project development was based on the operation process for System Development Service Provision (POP 20) The POP 20 procedures a sequence of activities and their expected outputs, auxiliary information and members re-sponsible for each activity taken. The development methodology roughly translates to the Unified Software Development Process (USDP).The USDP was chosen for its use-case driven, architecture-centric, iterative and incremental structure. Also, by applying this process, software development can produce high-quality software that meets the needs of its end-users within a predictable schedule.[5]
The USDP applies use-cases to capture soft requirements and to define the content of the iterations. The architecture is very important for this process being at the heart of the projects team’s effort to shape the system. The phases of this process (Inception, Elabo-ration, Construction, Transition) are divided into a series of time-boxed iterations. Each iteration resorts in an increment, which is a release of the system that contains added or improved functionality compared with the previous releases.[8]
Figure 2.4: Diagram illustrating the Unified Process flow. [9]
2.5
Tasks
Chapter 2. Project 9
Chapter 3
Context Study
Since the early 1950’s, the civil aviation has increasingly become a significant contribu-tor to the overall well-being and economic vitality of individual nations as well as to the world in general. One of the requirements of carrying out civil aviation activities is to ensure that a safe, secure, efficient and environmentally sustainable air navigation system is available, at the global, regional and national levels.[1]
Safety is the first concern of an Air Traffic Services Provider. In 1995, EUROCONTROL (European Organization for the Safety of Air Navigation) started its Air Traffic Services Safety Management program, which obliges all member States to implement a clear and systematic Safety Management System (SMS).
Advanced technologies have improved safety, so that even with substantial increases in air travel, the number of accidents involving civil transportation tends to be constant. One of the major contributors to this improvement is the air traffic control (ATC), which has the primary purpose of separating aircrafts to prevent collisions, to organize and expedite traffic flow, providing information and support to pilots. Even so, constant research is needed to discern, monitor and reduce the underlying causes of aircraft accidents.
With a good safety management system, the air traffic service providers may evaluate and control the effects of hazards associated with ATC. Following up on these hazards, from the conception phase of a new system until its withdrawal, is necessary and must be managed in a clear and efficient way.
NAV Portugal wants to maintain and improve its standards, providing an efficient, modern and lean air traffic service. With this in mind, NAV Portugal has been designing systems to implement good practices in operational tasks.
Safety is also the most important pillar of air navigation and for this reason NAV Portugal is continually investing in terms of safety innovation. NAV Portugal’s SMS approaches
the company’s activities in a systematic way, seeking excellence in the field of safety management. In the Air Navigation sector, SMS covers all of the services, people, infras-tructures, equipment, procedures, rules and information supplied to airspace users.[6]. The SMS is responsible for the identification, analysis and mitigation of possible risks; and reporting all occurrences so that they may be investigated and corrective measures be applied.
In the safety management area, there are a variety of concepts that can prove themselves ambiguous. This chapter aims to give the necessary background information and concepts avoiding any misconception regarding terms used throughout the project. Safety, hazards, occurrences and hazard logs are key notions that will be defined it the next sections.
3.1
Safety
While the complete elimination of accidents (and serious incidents) would be desirable, a one hundred per cent safety rate is an unachievable goal. Failures and errors will oc-cur, despite of the best efforts to avoid them. No human activity or human-made system can be guaranteed to be absolutely safe, i.e. free from risk. Safety is the state in which the risk of harm to humans or property damage is reduced to, and maintained at or be-low an acceptable level, through a continuing process of hazard identification and risk management.[17]
In many languages, like Portuguese, there is only one word that symbolizes both safety and security. Although the basic idea is the same for both, the meaning is different. This lack of direct translation can be fairly confusing when explaining the meaning and objectives of safety management. The basic idea of both is protecting assets from haz-ards/threats, creating safe/secure conditions. Safety is protection against hazards, while security is protection against threats.
Within the field of safety, hazards represent a potential danger for human health and lives, the environment, production and material objects. Also, an incident is often an unplanned event produced by human behavior in combination with the environment. In security, an incident is often the outcome of a set of planned malicious actions triggered by a per-son or a group’s will. Unlike hazards, threats are not always observable, tangible and proximate.[10]
Chapter 3. Context Study 13
3.2
Hazards and Occurrences
As defined in the previous section, a hazard is a situation in which there is potential dan-ger for people or the environment.
An occurrence is the actual materialization of a certain hazard. Occurrences can be ac-cidents, or incidents. An incident, or near miss, is an unintended event, or sequence of events, that do not result in loss but that under different circumstances may have the po-tential to do so.
Figure 3.1: Accident penetrating all defensive layers[24] Each hazard has its own causes, conditions, effects, barriers and mitigations.
Causes are events or latent conditions, that lead to a hazard under certain environmental conditions, e.g. the failure to detect a wrong input, may cause the undetected corruption of flight data for an aircraft, in an high traffic volume situation.
Having identified the hazards inherent to an activity, it becomes necessary to identify bar-riers that may provide effective control over these hazards. A barrier may turn access to dangerous processes or states impossible or difficult (a lockout), may make it difficult or impossible to leave a safe state or location (a lockin), or may enforce a sequence of actions or events (an interlock).[11] Barriers may be physical, procedural, administrative or human.[14]
To prevent hazards from developing into accidents, or to reduce their effects once they oc-cur it is necessary to identify and define mitigations.[13] Risk assessment and mitigation in Air Traffic Management (ATM) has to be performed by applying a process throughout the life cycle of the components that form the ATM system. A system is viewed as a combination of three constituents, humans, rules and procedures and physical equipment
1The terms "active" and "latent" as applied to errors were coined by James Reason[25] [26]. Active errors occur at the point of contact between a human and some aspect of a larger system, e.g. a human-machine interface. Latent errors, in contrast, refer to results or decisions taken by designers, manufacturers and senior management, this errors are less apparent failures of organization, or design, that contributed to the occurrence of errors or allowed them to cause harm.
(hardware and software).
When performing risk assessment and mitigation in ATM, the emphasis has to be placed on the process (hazard identification, effects identification and mitigations identification). However, quantification ensures that clear, unambiguous and agreed risk levels can be specified with an appropriate level of confidence.[35]
Figure 3.2: Example - Hazard’s Bow-Tie Diagram[20]
The occurrence reports are always very delicate, because they may contain information about incidents or accidents caused by human error.
Despite the existence of occurrences in this Hazard Logging System, it is not their pri-mary container. The system contains limited information about the occurrences, without any delicate details. The occurrences are used to have a global idea of the system’s state and to measure if the frequency of occurrences are within the desired value range. In time, with this data, the safety management team may see if the barriers and mitigations are being effective, or if the initial probability of occurrence is realistic. For more detailed information about a certain occurrence, the system contains references to the source doc-uments, or to the persons responsible for reporting that occurrence. Most of the time the person responsible for an occurrence is not the person that writes the information in the system. So, both entities should be modeled.
Both hazards and occurrences have effects, but they may not be the same. Hazards are theoretical potential dangers, so their effects are the expected, theoretical effects. But the planned may not be the same as the reality. The total loss of the radar picture for two minutes, if occurring at a high peak traffic time, can cause a severe incident. But the same hazard, occurring when there is almost no traffic and the aircrafts are well separated, re-sult in no more then an inconvenience. For this reason, both hazard and occurrences may have different effects. This makes it easier to see if a hazard leads to the expected effects and, if not, what and why was the outcome different. Also, the severity of the effects of hazards and occurrences are classified in a distinct way. The hazards severity is classified by EUROCONTROL Safety Regulatory Requirement 4 (ESARR 4) and the occurrences
Chapter 3. Context Study 15
severity classification is based in the EUROCONTROL Safety Regulatory Requirement 2 (ESARR 2).
According to ESARR 4, the severity of the effects of hazards in a given environment shall be determined using the classification scheme shown below in the table 3.1. This scheme provides a quantitative ranking for the severity/magnitude of the hazard effects on operations, which may arise from the various ATM System components.
Severity Class 1 2 3 4 5
Effect on Accidents Serious Major Significant No immediate
Operations incidents incidents incidents effect on safety
Table 3.1: Severity Classification Scheme in ATM [15]
Usually, as there is no accident/incident causation model, the severity classification re-lies on a specific argument demonstrating the most probable effect of a hazard under the worst credible scenario. With the introduction of this project, all effects may, in time, be classified, instead of only the most probable effect, under the worst credible conditions. In ESARR02 the severity classification scheme of occurrences is defined according to the severity of their effect on the ability to provide safe Air Traffic Management Services. The Severity Classification Scheme consists of categories of severity and for the frequency of their occurrence. These are combined as a classification matrix whose columns corre-spond to the frequency categories and rows correcorre-spond to the severity categories shown in table 3.2.
Table 3.2: Severity Classification Scheme for ATM specific occurrences [16] The Severity Classification Scheme considers the actual frequency of each of these occur-rences to enable the determination of the level of effort to be placed into the assessment of the occurrence, as well as to support the development of trends in safety.
3.3
Risk Classification
The aviation industry faces a diversity of risks every day, many of them capable to com-promise the viability of an operator, and some even posing a threat to the industry. Daily, decisions are made in real time, weighing the probability and severity of any adverse con-sequences implied by the risk against the expected gain of taking the risk.[17]
A risk is the assessed potential for adverse consequences resulting from a hazard. It is the likelihood that the hazard’s potential to cause harm will be realized. Risk assessment in-volves consideration of both the probability and the severity of any adverse consequences. In other words, the loss potential is determined. In carrying out risk assessments, it is important to distinguish between hazards (the potential to cause harm) and risk (the like-lihood and impact of that harm).
A Risk Classification Scheme/Matrix is often very useful, because it specifies the maxi-mum acceptable and tolerable frequencies of occurrence of a (hazard) effect of a certain severity class per reference unit (flight hour, operational hour, per sector, etc.) It is derived in accordance with the definition of risk.[18]
Table 3.3: Example - Risk Classification Scheme[18]
3.4
Safety Objective
Safety Objectives are defined in ESARR4 as a quantitative or qualitative statement that de-fine the maximum frequency or probability at which a hazard can be expected to occur.[19] For this project the definition of Safety Objective (SO) will follow the ED-125. So, a safety objective is defined as a quantitative statement that defines the maximum frequency
Chapter 3. Context Study 17
or probability at which a hazard can be accepted to occur.[35]
To derive the SO, it is essential to understand also that the ATMSP is obliged to Safety Targets. Safety Targets (STj) specify the overall maximum frequency of occurrence of effects of any type having a given Severity Class j (SCj), whatever the ATM cause.
3.4.1
Safety Objectives Quantification
There are four models for quantifying SO:
• Quantitative Model - The SO is derived considering all effects, Peijper effect (prob-ability that once a hazardi has occurred, it generates an effect with the severityj of each hazard and the total number of hazards.)
• Semi-Quantitative Model - The SO is derived by considering the worst credible effect per hazard, Peij per hazard and the number of hazards.
• Semi-Prescriptive Model - The SO is derived by considering the worst credible effect, Peij, number of hazards per Severity Class and the airspace complexity. • Fixed Prescriptive Model - The SO is derived by considering the worst credible
effect and airspace complexity.
The quantitative model was the chosen model for the derivation of the safety objectives for being the most complete model. This model has some limitations that will be explained throughout the model application illustration.
3.4.2
Qualitative Model
The quantitative model provides a full alignment with the risk definition, produces safety objectives more precise and accurate, but also requires a lot of effort in the identification of all the effects and probabilities.
Firstly, the Risk Classification Scheme (RCS) is derived from the national regulator’s Safety Target specifications, shown in table 3.4, incorporating an Ambition Factor (AF) of 10. The Ambition Factor is a number greater or equal to one that is used by the ATM-SPs when setting their acceptable Safety Targets by dividing the tolerable Safety Targets set by the National Regulator(NR) by this AF.[35]
Safety Target National Regulator
maximum Safety Target(/fh)
ST1 1 E -8
ST2 1 E -5
ST3 1 E -4
ST4 1 E -2
ST5 n/a
Table 3.4: Specification of National Regulatory RCS[35]
Safety Target ATMSP AF (Max Safety Target /fh)
ST1 10 1 E -9
ST2 10 1 E -6
ST3 10 1 E -5
ST4 10 1 E -3
Table 3.5: Specification of ATMSP RCS[35]
The number of flight-hours per year of this ATMSP is 350000. Hence, the Safety Targets (ST) can be converted to units of "per year" where:
ST(/year) = ST(/flight hour)* 350000(flight hours per year)
Severity of the effect ATMSP Safety Target: ATMSP Safety Target:
Maximum acceptable Maximum acceptable
frequency of occurrence frequency of occurrence of an effect (/fh) of an effect (/y)
SC1 ST1= 1 E -9 /fh ST1= 35 E -5 /y
SC2 ST2= 1 E -6 /fh ST2= 35 E -2 /y
SC3 ST3= 1 E -5 /fh ST3= 35 E -1 /y
SC4 ST4= 1 E -3 /fh ST4= 350 /y
Table 3.6: ATMSP RCS
Also, the system has the total hazards identified at the ATM service provision level (N), the total hazards significantly contributing to any kind of STj(Nj) and their likely effects. For a particular hazard (Hazard A) the likely effects and their relative probabilities (Pe). This probability is exemplified in the following figure.
Chapter 3. Context Study 19
Figure 3.3: Quantitative Model Hazard Safety Objective Example
The probability of a hazard leading to a certain effect can prove to be difficult to obtain due to the mitigations that have to be taken into account. The best way to manage this difficulty is to work with specialized software for those calculations.
After determining the probability the safety objective is calculated as showed in the pre-vious example:
SOi =min(STj/Peij/Nj) where j = (1,2,3,4,) is the Severity Class
So, in the case of the example, the maximum frequency of the hazard "A" has to be 7 E -1 occurrences year.
3.5
Safety Management
Although air accidents are rare events, less catastrophic incidents occur more frequently. These less significant events may be harbingers of underlying safety problems. Ignoring them could pave the way for an increase in the number of more serious accidents. Ac-cidents and inAc-cidents cost money. An understanding of the total costs of an accident is fundamental to understanding the economics of safety. The air transportation industry’s future may well be predicated on its ability to sustain the public’s perceived safety while traveling.
The hazards may either become evident after an accident or incident, or may be pro-actively identified through formal safety assessment before an actual safety event occurs. Safety management is centered on a systematic approach to hazard identification and risk management in the interests of minimizing the loss of human life and money through pro-active measures.
Chapter 3. Context Study 21
Safety management is multidisciplinary domain, requiring the systematic application of a variety of techniques and activities. It builds upon three defining cornerstones:
• A comprehensive corporate approach to safety, building upon a positive safety cul-ture and embracing the organization’s safety policies, objectives and goals, and, most importantly, senior management’s commitment to safety, always actively seek-ing to improve.
Table 3.8: Comparative benefits of a positive safety culture[17] • A formal system for safety oversight. This is needed to confirm the organization’s
continuing fulfillment of its corporate safety policy, objectives, goals and standards. • Organizational tools to deliver safety standards. Effective organizational tools are
needed to deliver the necessary activities and processes to advance safety.
3.6
Computational Support
Safety management is evidence-based, in that it requires the analysis of data to identify hazards. Using risk assessment techniques, barriers and mitigations are set for reducing the potential consequences of the hazards. Strategies to eliminate and mitigate the hazard potential effects, are then developed and implemented with clearly established account-abilities. The situation is assessed on a continuing basis, and additional measures are im-plemented as required. The computational support to hazard management will make the
Chapter 3. Context Study 23
process more clear, agile, accessible, promoting collaboration and a better understanding of safety culture.
3.7
Hazard Logging
A hazard that has not been identified cannot be controlled. Accordingly, an identified haz-ard that is not easily accessible will hhaz-ardly be followed. Hazhaz-ard Logs play an important role in this last implication. They are most commonly defined as a collection of informa-tion about hazards relevant to the system, or product in quesinforma-tion. It should act as a central repository for the management and demonstration of on-going safety activities, contain-ing information on all possible hazards, even ones that are not considered credible. Also, it should contain the documentary evidence of risk handling, providing vital information for the construction of safety cases.[3]
Safety cases are an important part of goal-based safety regulations and corporate gover-nance. A safety case is a documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environ-ment.
Despite the hazard logging activity importance within the safety management being ut-terly described by guidance material [4] [17], and authors, such as, Richard Maguire [3], log report component’s description is scarce. Most times, the available material is super-ficial, miscellaneous and based on paper reports.
The lack of a central and reliable source of information about hazard logging during the analysis phase, originated an cyclic process of bibliographic study and stakeholders revi-sion, strongly guided by past difficulties, actual FHA reports information, shown in figure 3.6, and regulators requirements.
Chapter 4
Project Development
4.1
Project Requirements
Requirements gathering was an essential part of this project, defining the needs and con-ditions required for the hazard logging and management system. Since NAV Portugal did not presented a fully developed requirements specification, the requirements were as-sessed through a series of meetings with the stakeholders, analysis of existing hazard logs and the study of international standards and requirements. The requirements were docu-mented in the System Specification Document (DES) and approved by the reviewers and stakeholders. The aim of DES is to document all of the requirements identified during the analysis phase, translating them into the projects system specifications. This document also has the goal of identifying all the needs for interfaces, performance, capacity, envi-ronment, use, reliability, safety, security, installation, quality and design constraints. All the requirements were modeled with Enterprise Architect, an UML 2.1 team-based modeling environment that embraces the full product development life-cycle, offering high-performance visual tools for business modeling, systems engineering, enterprise ar-chitecture, requirements management, software design, code generation, testing and oth-ers. Enterprise Architect provides traceability of requirements, analysis and design mod-els throughout the implementation and deployment phases.
Despite the tool’s usefulness, it proved itself very time consuming in the requirements specification. Also, the existing Enterprise Architect template document had to be com-pletely altered, so that the outcome document was in conformity with the NAV Portugal rules.
This section summarizes the system requirements (fully documented in the System Spec-ification Document, in the given Annex).
4.1.1
Users
Four main types of users, with different permission levels, were identified. The main users are successive specializations of the administration, the user that has access to all of the system’s functionalities.
4.1.2
Functional Requirements
Functional requirements define the functions of a system, or its component, describing and capturing them in use cases. Each use case illustrates behavioral scenarios through one or more functional requirements. For a better understanding, the functional require-ments were divided into four modules:
• User Management - Groups all the functionalities related with user registration and management.
• Hazard Environment Management - Groups all the functionalities related with the management of hazard ancillary information, such as causes, conditions and barri-ers. This module helps relieving users from repeatedly writing by hand the same information. Besides all the CRUD functions it was required more complex func-tions:
– All records had to be searchable by all the their characteristics, e.g. obtain the list of all effects of severity 2.
– It was required to know how many hazards were associated with each bar-rier, cause, condition, mitigation, ESARR 04 severity and effect. It was also needed to know how many occurrences were associated with each ESARR 02 severity or effect. This enables the user to see, for example, if an identified effect with a severity 2 was identified in any occurrence.
• Hazard Management - Groups hazard management functionalities. These func-tionalities include hazard and occurrence addition, with direct addition of auxiliary information, list filtering, or record removal. Besides all the CRUD functions it was required more complex functions:
– Both hazards and occurrences had to be searchable by all the their characteris-tics and associated information to, for example, obtain the list of all the open hazards for the Lisbon Tower with a certain barrier and mitigation or how many hazards were identified in the last year for the Lisbon ATM. In the oc-currence case, this functions can, for example, show the list all the ococ-currences of a certain hazard this year.
– It was required to know how many barriers, causes, conditions, mitigations and effect were associated with each hazard.
Chapter 4. Project Development 27
• Action Log - Set of functions that allow the administrator and the risk manager to analyze and perform rollback actions to all the actions performed by the users. This functions allow not only the user to be more at ease with the system, but also, to acknowledge if any user is consistently adding or editing incoherently the information.
In contrast with the Use Case Diagrams, the Use Case Descriptions capture variations of a Use Case. In this project there are casual use descriptions, summarizing the use case in a few paragraphs and fully dressed use cases based on a detailed template with fields for various sections as shown in the next image.
Figure 4.1: Example of a formal use case description.
4.1.3
Non-Functional Requirements
Non-functional requirements specify constraints and features beyond the system oper-ations. For a better understanding, the requirements were divided into several groups: extensibility, maintainability, performance, quality, security and usability. A fully dressed description is provided in annex.
technologies. All the decisions that arose from this requirements are explained in the following chapters.
4.2
Data Model
One of the most important parts of this project is the definition of an abstract model that described how hazard data is represented. These models formally define data elements and relationships among data elements for a domain of interest.
4.2.1
Entity-Relationship Model
During the requirements analysis a conceptual representation of hazard information was needed. The entity-relationship model (ERM) was the model chosen for its top-down approach. This scheme evolved during the requirement gathering phase and it was very useful in meetings, making it simple to understand and interact.
In the first versions of the model, all the information was very disperse representing all the ideas and information known in each iteration, but without any real organization or structure.
Chapter 4. Project Development 29
As the information was consolidated more stable links were established and the final structure began to form.
Each hazard affects only a system and a function, different systems have different hazards with different probabilities of occurring. A hazard can be in three states, open if a hazard still affects a system, closed if it does not affect any more or when a system is no longer in use, or undefined if there is a doubt concerning its state. Also, as previously mentioned, each hazard can have several cases, barriers and occurs in determined conditions.
For each hazard several mitigations can be defined. A department is responsible for car-rying out mitigation till a closure date. By that time the status of that mitigation should be closed.
The occurrences appeared in the model when the necessity for more information about the hazard was felt. Each hazard can have several occurrences, but an occurrence is only linked to a hazard. By having the abstract idea (hazard) and the materialization of that idea (occurrence) it is easier to understand if the safety targets are being met, if the barri-ers and mitigations are being effective and if the real effects were the expected ones. Also, new hazards can appear from occurrences they can not attribute a know hazard, being a good indicator that this occurrence needs to be investigated.
When a hazard is linked to effects with a determined severity the safety objective is au-tomatically calculated. The safety objective value is based on the qualitative model, as explained in the section 3.4.2.
The occurrence only has the information important for hazard analysis, not containing confidential information. For that reason there are to entities involved. The system user responsible for writing the report on the system, and a person responsible for providing the information,. That way for more detailed information they can contact the responsible for the information.
4.2.2
Integrity Rules
Integrity rules ensure that data entered into the database are accurate, valid, and consistent. Any applicable integrity constraints and data validation rules must be satisfied before permitting any change to the database. During the modeling process, the domain, key, entity and referential integrity were respected. This means that data predefined types are respected, too distinct tuples of the same relation can not have the same key value, one attribute that makes up the primary key can not be null and finally, in a relation, any foreign key occurrence has to refer to an existent primary key of the other table.
Additional restrictions appeared during the modeling phase:
• In Department, name is candidate key; and in User, name and employeeNumber are candidate keys.
for-Chapter 4. Project Development 31
eign key is not null. In the Hazard Mitigation relation, the attributes status, closure date, comment and author can only be filled if the foreign key is not null. In the Occurrence Effect relation, the attribute comment can only be filled if the foreign key is not null.
• The foreign key of Occurrence for User and Department can not have null values. The foreign key of User for Department can not have null value. The foreign key of Mitigation for Department can not have null value. The foreign key of Effect for SeverityH can not have null values.
• The foreign key of Effect for SeverityO only may have value different from null when the given Effect is associated with an Occurrence.
• For all the generalization occurrences, it has to exist an occurrence (ID) in at least one of the sub-entities. For each occurrence of the generalization, it can only exist on sub-entity (ID).
4.2.3
Relational Model
The relational model permits the database designer to create a consistent, logical repre-sentation of information.
• Causes(identification, description) • Conditions(identification, description)
• Barriers(identification, description, probEfficacy) • Mitigations(identification, description)
• Departments(acronym, name, description) • SeverityH(classification, description) • SeverityO(classification, description)
• SafetyObjClaSchema(identification, classification)
• User(userName, name, pass, email, permissions, Department.acronym) • Effect(identification, SeverityH.classification, description)
• Hazard(identification, author, system, function, status, safObj, probability, com-mentH)
• Occurrence(identification, Hazard.identification, dDescription, description, dateO, timeO, commentO, Department.acronym, reporter, User.id)
• HazardBarrier(Hazard.identification, Barrier.identification) • HazardCause(Hazard.identification, Cause.identification)
• HazardCondition(Hazard.identification, Conditions.identification) • HazardEffect(Hazard.identification, Effect.identification, probability )
• HazardMitigation(Hazard.identification, Mitigation.identification, author, respon-sible, statusM, closureDate, commentM)
• OccurrenceEffect(Occurrence.identification, Effect.identification, commentOE, SeverityO.classification)
Chapter 4. Project Development 33
4.2.4
Database Model
4.3
Architecture
Following the requirements gathering and data model definition phases, it was essential to abstractly define the system’s structure.
The system architecture is a conceptual representation, based on the abstraction of dif-ferent architectural details, which mainly intends to describe the structure of the system. This chapter will address the choices made with regard to the systems architecture and how this influenced the final solution, as well as why these decisions where taken. A more in-depth view of the system architecture is provided in the implementation chapter, along with particular details on the adopted technology.
One of the main architectural decisions that was made is the Web service approach in-corporating the Model View Controller pattern. This approach besides all the inherent advantages, also provides coverage of some of the non-functional requirements like, easy interoperability between various software applications or Internet access for several users with different types of system permissions.
4.3.1
Web services
One of the first choices made in regard to the system architecture was the adoption of a Web-based architecture. This decision proved to be advantageous in terms of system development and installation/configuration, due to its simplicity. If the architecture had a traditional solution (thick client), additional steps would have to be taken in regard to computer installation and configuration, in addition to the lack of platform and device independence.
Web services provide interoperability between various software applications running on disparate platforms and locations. Web Services use open standards, data formats and pro-tocols that can be text-based, making it easy for developers to comprehend. By utilizing HTTP, Web Services can work through many common firewall security measures without requiring changes to the current firewall filtering rules. Web Services also promote the reuse of services and components within an infrastructure.[31]
Chapter 4. Project Development 35
Figure 4.4: Platforms and devices
Despite the countless other benefits provided by Web services, there are also some dis-advantages in terms of development. Due to lack of state of this type of architecture, there are some difficulties in the system’s implementation and performance. Many of these problems can be overcome using the concept of session, offered by programming languages like Java. Sessions are a set of data temporarily stored on the client’s machine that is sent to the server whenever the user performs an action, thus overcoming most of the problems that are state related.
There are several ways to use Web Services, the three most common styles are RPC (Remote Procedures Call), SOA (Service-Oriented Architecture) and REST (Represen-tational State Transfer). This project uses REST, attempting to describe the architecture using HTTP, with a set of well-known, standard operations like GET, POST, PUT and DELETE. Although using HTTP, for communication, the services layer is completely in-dependent of the HTTP protocol. This is achieved by creating a separate service layer between the actual service and the web browser, which uses HTTP. This intermediate layer is responsible for translating HTTP messages to an independent data format used by the services layer. This separation enables other types of clients to easily access the services layer by simply replacing the HTTP service layer.
Figure 4.5: Independent Data Layer
4.3.2
REST
REST-style architectures have clients and servers, where clients initiate requests to servers and servers process requests and return appropriate responses to clients. Requests and re-sponses are built around the transfer of "representations" of "resources". A resource can be essentially any coherent and meaningful concept that may be addressed. A representa-tion of a resource is typically a document that captures the current or intended state of a resource. At any particular time, a client can either be transitioning between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the set of servers or on the network.[44] The client begins sending requests when it is ready to transition to a new state. While one or more requests are outstanding, the client is considered to be transitioning states. The rep-resentation of each application state contains links that may be used next time the client chooses to initiate a new state transition.[43]
REST was initially described in the context of HTTP, but is not limited to that protocol. RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state. RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it. The REST ar-chitectural style describes the following six constraints applied to the architecture, while leaving the implementation of the individual components free to design:
• Client–Server - Clients are separated from servers by a uniform interface. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code
Chapter 4. Project Development 37
is improved. Servers are not concerned with the user interface or user state, so that servers can be simple and scalable. Servers and clients may also be replaced as long as the interface is not altered.
• Stateless - The client–server communication is further constrained by no client text being stored on the server between requests. Each request from any client con-tains all of the information necessary to service the request, and any state is held in the client. The server can be stateful, this constraint merely requires that server-side state be addressable by URL as a resource. This not only makes servers more visible for monitoring, but also makes them more reliable in the face of network failures, as well as further enhancing their scalability.
• Cacheable - As on the World Wide Web, clients are able to cache responses. Re-sponses must therefore, implicitly or explicitly, define themselves as cacheable or not to prevent clients reusing stale or inappropriate data in response to further re-quests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
• Layered System - A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary server. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.
• Code on demand - Servers are able to temporarily extend or customize the func-tionality of a client by transferring logic to it that it can execute. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.
• Uniform interface - The uniform interface between clients and servers, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below.
The uniform interface between clients and servers that any REST interface must provide is considered fundamental to the design of any REST service and has the following char-acteristics [44]:
• Identification of resources - Individual resources are identified in requests, for ex-ample using URIs in web-based REST systems. The resources themselves are con-ceptually separate from the representations that are returned to the client. For exam-ple, the server does not send its database, but rather, perhaps, some HTML, XML or JSON that represents some database records expressed, for instance, in French and encoded in UTF-8, depending on the details of the request and the server im-plementation.
• Manipulation of resources through these representations - When a client holds a representation of a resource, including any metadata attached, it has enough infor-mation to modify or delete the resource on the server, provided it has permission to do so.
• Self-descriptive messages - Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cacheability.[45]
• Hypermedia as the engine of application state - If it is likely that the client will want to access related resources, these should be identified in the representation returned, for example by providing their URIs in sufficient context, such as hypertext links.
4.3.3
Model View Controller Pattern
Like many computer systems, the purpose of this project can be reduced to retrieve data from a data store and display it for the user. After the user changes the data, the system stores the updates in the data store. Because the key flow of information is between the data store and the user interface, it is easy to tie them together to reduce the amount of coding and to improve application performance.[42] However, this seemingly natural approach has some significant problems:
• The user interface logic and business logic is separated, because interface logic tends to change more frequently than business logic, especially in Web-based ap-plications. For example, new user interface pages may be added, or existing page layouts may be shuffled around. After all, one of the advantages of a Web-based thin-client application is the fact that the user interface can be changed at any time without having to redistribute the application. If presentation code and business logic are combined in a single object, it is necessary to modify an object containing business logic every time you change the user interface. This is likely to intro-duce errors and require the retesting of all business logic after every minimal user interface change.[43]
• Designing visually appealing and efficient pages generally requires a different skill set than does developing complex business logic. So it is desirable to separate the development effort of these two parts.
• User interface activity generally consists of two parts: presentation and update. The presentation part retrieves data from a data source and formats the data for display. When the user performs an action based on the data, the update part passes control back to the business logic to update the data.
Chapter 4. Project Development 39
• The user interface code tends to be more device-dependent than business logic. If there is a need to migrate the application from a browser-based application to support personal digital assistants (PDAs) or Web-enabled cell phones, much of the user interface code must be replace, whereas the business logic may be unaffected. A clean separation of these two parts accelerates the migration and minimizes the risk of introducing errors into the business logic.
• Creating automated tests for user interfaces is generally more difficult and time-consuming than for business logic. Therefore, reducing the amount of code that is directly tied to the user interface enhances the testability of the application.[43] The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes[29]:
• Model - Manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
• View - Renders the model into a form suitable for interaction, typically a user in-terface element. Multiple views can exist for a single model for different purposes. • Controller - Receives input and initiates a response by making calls on model ob-jects. A controller in this web tier performs the interception of HTTP requests, from the client, translates each request into a specific business operation to be performed, then invokes the specific operation or delegates it to a handler, helps to select the next view to be presented to the client and returns the view to the client.
4.4
Technologies
In order to attain the project’s requirements, and architecture a variety of technologies were chosen. This decisions took into account that the technologies used had to be free, enable the project’s evolution and data reliability and availability.
This chapter describes and discusses the decisions taken in regard to the chosen technolo-gies. These technologies are represented in the following technology stack diagram.
