development of a personal protective equipment management system for a rope access company

Andrzej Kurczych TM470 EMA PI: B6142764

Development of a PersonalProtective Equipment

Management System for a ropeaccess company

TM470

A. Kurczych

PI: B6142764

11 September 2017

1


Contents

Front Page 1

Contents 2

1 The project plan

1.1 Description and scope 4

1.2 Project tasks 8

1.3 Lifecycle model and schedule 8

1.4 Resources, methods and skills 9

2 The project work

2.1 Literature 11

2.2 Developing the system 14

2.3 Legal, social, ethical and professional issues 26

3 Review and reflection

3.1 Review of current stage of project work 28

3.2 Project management review 31

3.3 Resources and methods review 33

3.4 Skills development review 35

References 37

Software Resources 39

Bibliography 40

Appendix 1: Examination report 41

Appendix 2: Requirements of PPE Management System 42

Appendix 3: Project schedules 45

Appendix 4: System architecture 48

Appendix 5: Analysis of lifecycle models 49

Appendix 6: Risk registers 50

Appendix 7: Assessment of credibility of information sources 52

2


Appendix 8: Business rules 54

Appendix 9: Business processes 58

Appendix 10: Domain structural model and glossary 60

Appendix 11: Use case models 66

Appendix 12: Detailed software functional requirements 70

Appendix 13: Analysis models 72

Appendix 14: Design models 81

Appendix 15: persistence.xml file 86

Appendix 16: Entities and their tests 87

Appendix 17: Enterprise JavaBeans and their tests 103

Appendix 18: Web pages navigation plan 120

Appendix 19: Web pages and backing beans 122

Appendix 20: Screenshots of web pages 133

Appendix 21: Requirements-based testing 141

Appendix 22: Stakeholders impact analysis 146

Appendix 23: Sample project journal entry 148

Appendix 24: Communication with the tutor 149

3


1 The project plan

1.1 Description and scope

1.1.1 Background

A company providing rope access services requires a computer system to manage its Personal

Protective Equipment (PPE). Appropriate control and maintenance of rope access equipment are

crucial for the safety of its users. Any PPE used for work at height must be used and maintained in

accordance with The Lifting Operations and Lifting Equipment Regulations 1998 (LOLER). Regulation 9

(Great Britain, The Lifting Operations and Lifting Equipment Regulations 1998) states that PPE must

be thoroughly examined:

before first use;

at least every 6 months or in accordance with an examination scheme drawn up by a

competent person;

after events that have potential to jeopardise the safety of the equipment.

Regulation 10 states that a report must be produced following a thorough examination and

Regulation 11 specifies the period of retention for such report. Additionally, Schedule 1 details

information that should be contained in examination reports. Appendix 1 contains an example of an

examination report.

Industrial Rope Access Trade Association (IRATA) published IRATA International code of practice for

industrial rope access (ICOP). IRATA's recommendations related to PPE examination are in line with

the requirements of LOLER. However, ICOP includes an additional guidance on record keeping.

Section 2.9 (IRATA International, 2014) contains a list of records that should be maintained about

each individual item of PPE.

1.1.2 The problem

Currently, the company stores all records on paper which causes a number of issues. Records have to

be checked on regular basis to ensure that examinations are not missed. During long-term projects,

equipment records are kept on sites and thus are not available in the office for scheduling

examinations. Some of the records recommended by IRATA, such as the duration of active use, are

difficult to maintain and thus are not kept.

The above issues pose a risk of equipment missing examinations required by LOLER, especially when

equipment records are not available in the company's office. It is also possible for equipment to be

used beyond the lifespan recommended by manufacturers.

4


1.1.3 The solution

A computer system could improve the way PPE examinations are tracked and equipment records are

maintained. The proposed software system would allow to:

store equipment records in a database;

store examination reports and inspection records in the database;

notify about forthcoming examinations and equipment's lifespan coming to the end;

create examination schedules;

store records about the active use of equipment, its current location and user.

access all the data from various locations and devices over the Internet.

1.1.4 Likely impact

Using the proposed software system should ensure that PPE examinations are always up-to-date in

accordance with the relevant regulations. It should also enable staff to record more equipment data

as recommended in the relevant guidelines, allowing better estimation of equipment lifespan and

tracking equipment location. Ultimately, these enhancements should lead to improvement of

workplace safety in the high-risk industry.

The proposed software system may also have a negative impact on the company's personnel. Storage

of personal data on the system accessible over the Internet will expose it to attempts of

unauthorised access. Additionally, managers and supervisors may experience a small increase in

workload as more PPE details will need to be recorded.

1.1.5 Project Scope

The initial scope of the project

Appendix 2 contains a list of functional and non-functional requirements of the proposed system.

However, implementing all these requirements would require significantly more time than available

within a TM470 project. The following functional requirements were thus selected for the output of

this project:

FR1: The system will permit a new equipment record to be added to a database.

FR2: The system will permit an existing equipment record to be viewed.

5


FR4: The system will permit an existing equipment record to be deleted.

FR5: The system will permit a new examination report to be added to a database.

FR6: The system will permit an existing examination report to be viewed.

FR10: The system will notify users when an item of equipment is due for examination within

1 month.

FR11: The system will notify users when examination of an item of equipment is overdue.

The following non-functional requirements were also selected:

NFR1: The system shall be accessible over the internet via a desktop web browser.

NFR5: The system shall recover from failures without any data loss.

NFR6: The system shall support concurrent access from multiple users.

NFR9: The system shall be able to be modified to cope with changes in functional and non-

functional requirements.

NFR10: The system shall be able to be modified to cope with new functional and

non-functional requirements.

NFR11: The system shall be compliant with The Lifting Operations and Lifting Equipment

Regulations 1998.

NFR12: The system shall be compliant with IRATA International code of practice for industrial

rope access.

NFR13: The system shall be compliant with Data Protection Act 1998.

NFR16: System shall be accessible to registered users only.

NFR17: Registered users shall be able to access only the functionality allocated to their role

within the system.

Scope after the review at TMA01

A progress review was conducted as part of TMA01 work. Since it showed that the project was

progressing in accordance with its schedule (see Figure A3.2 in Appendix 3) no change to the scope

was required.


Another progress review was conducted as part of TMA02 work. It was estimated that the project

was approximately two weeks behind its schedule, due to delays described in detail in Section 2.2.1.

6


It was however decided that the best time to adjust the project plan, and possibly the scope, would

be after Increment 1.

Scope after the Increment 1 review

The review conducted at the end of Increment 1 (see subsection 'Project plan and risk register

review' in Section 2.2.1) revealed that the project was three weeks behind its schedule (see Figure

A3.1 in Appendix 3). It also looked unlikely that the two remaining increments could be completed

within the allocated timeframe. A decision was thus made to reduce the number of increments from

three to two (see Figure A3.2 in Appendix 3). This meant that NFR13, NFR16 and NFR17, all relating

to the security of the system, were removed from the scope of this project.


Following the earlier change to the project schedule, the TMA03 progress review showed that the

project was one week behind its plan. It was decided that despite the delay it should be possible to

complete the project within the allocated timeframe and no change to the schedule or scope is

required.

The final scope of the project

With one change to the initial scope of the project after completion of Increment 1, the final scope of

the project consisted of the following requirement from the initial list: FR1, FR2, FR4, FR5, FR6, FR10,

FR11, NFR1, NFR5, NFR6, NFR9, NFR10, NFR11 and NFR12.

1.1.6 Architecture of the system

Analysis of the non-functional requirements led to the selection of the classic three-layer

architecture for the system. The persistence layer would be required for persistent storage of PPE

data and fault tolerance (NFR5). The business layer would handle concurrent access to the database

from multiple users (NFR6) and security (NFR13, NFR16 and NFR17). The functional requirements

would also be implemented in this layer. Finally, the presentation layer would deal with the

generation of the graphical user interface and would provide access to the system over the Internet

(NFR1). Appendix 4 contains a diagram of the proposed architecture implemented using Java

Enterprise Edition.

7


1.2 Project tasks

The following main tasks were identified for the project.

Concept development involved identification of project requirements, choosing the area and the

topic of the project, and preparation of a proposal.

Project planning was concerned with the identification of major tasks, selection of project's life

cycle, the creation of a project schedule and risk assessment. Analysis of resources, methods and

skills required for the project was also carried out.

Research covered identification and analysis of sources of information.

Domain modelling involved analysis of information related to the problem domain. Business rules

and processes were specified and a domain structural model was created.

Requirements phase was concerned with the identification of functional and non-functional

requirements. A use case model was used to capture detailed software requirements.

In Analysis the domain structural model created earlier was converted into an analysis structural

model. The system operations were also specified.

Design involved allocation of responsibilities to system's components to achieve objectives of system

operations.

In Implementation and testing, the design model was used to implement the system and its tests.

Evaluation and review phase covered evaluation of the product by a client representative and review

of various aspects of the project.

1.3 Lifecycle model and schedule

Following a consideration of relative strengths and weaknesses of the main alternatives (see Table

A5.1 in Appendix 5), the incremental lifecycle model was chosen for the project. The main reason

was that it was possible to decompose the PPE Management System into smaller parts, that could

then prioritised. The core features such as storage of PPE records and keeping track of examinations

would be implemented first, followed by other less essential requirements. With the limited time

available, the chosen lifecycle model would enable delivering of an incomplete but working solution

and adjusting the number of implemented features depending on the progress.

The incremental lifecycle model used for the project was based on the development process

presented in TM354 Software engineering (The Open University, 2014b). The lifecycle model and the

tasks presented in Section 1.2. were used to create a detailed project schedule (see Table A3.1 in

Appendix 3) as well as Gantt charts of the project schedule (see Figures A3.1 and A3.2 in Appendix

3).

8


1.4 Resources, methods and skills

Methods

The Open University (2014a) used the term plan-driven development to describe a traditional and

detailed approach to software development as opposed to light-weight and faster agile approaches.

Although the approach taken in this project is not strictly classified, it is closer to plan-driven

development. This is because agile approaches require some experience to be able to decide which

analysis or design tasks are not required. One of the objectives of this project was to gain that

experience.

Since the primary purpose of the system was to store information about real items, object-oriented

design and implementation were chosen for the project. Additionally, object-oriented software is

often easier to understand and maintain (Deitel, P. and Deitel, H., 2015), which should help to satisfy

NFR9 and NFR10 (see the subsection 'The initial scope of the project' in Section 1.1.5).

Test-driven development (TDD) method, where tests are written before the code being tested, was

selected for the project. Its main benefit is spreading of testing throughout the development process.

An alternative approach, where testing is the final phase of the project, may result in tests being

rushed or not completed at all.

Resources

PPE Management System is a typical enterprise web application and could be implemented using a

variety of frameworks. Java Enterprise Edition 7 (Java EE 7), available from Oracle (2017a), was

chosen for a number of reasons. Prior knowledge of Java language and Java EE was the main

argument. Another advantage of Java EE was that it is a collection of open standards with a number

of specific implementations to choose from, often available under open-source licenses. Possible

alternatives include .NET or Meteor platforms. The main disadvantage of .NET framework (Microsoft,

2017) for this project was that it would require learning one of its programming languages and the

framework itself. It is also associated with Microsoft's proprietary environment. Meteor (Meteor

Development Group, 2017) is JavaScript centred platform. Again, its main disadvantage was that it

would require to improve knowledge of JavaScript and to learn the platform itself. It is also relatively

new technology so it may not be suitable for a project that would benefit from a long-term support.

Following evaluation of dynamic web page generation technologies (see Section 2.1 of Part 2)

JavaServer Faces (JSF) was selected for implementation of the presentation layer.

There is a range of IDEs to choose from for Java EE development, including NetBeans IDE (Oracle,

2017b), Eclipse IDE (Eclipse Foundation, 2017) and IntelliJ IDEA (JetBrains, 2017). NetBeans 8.2 was

chosen because it is available under an open source license bundled with other Java EE components

and the author is familiar with it.

There are a number of application servers to choose from, including GlassFish (Oracle, 2015) and

JBoss Enterprise Application Platform (Red Hat, 2017b). GlassFish was selected as it is the Reference

9


Implementation (RI) of the relevant Java EE standards, which ensures compliance with their latest

versions. It also came bundled with Java EE, which reduced the amount of configuration required.

Although it is possible to use Java EE with NoSQL databases (Red Hat, 2017a) such as MongoDB

(MongoDB, 2017), relational databases are a proven solution. Since PPE data is highly structured and

should fit on a single server, a relational database was selected for persistent storage. A number of

open source relational databases are available such as MySQL (Oracle, 2017c) or PostgreSQL (The

PostgreSQL Global Development Group, 2017). The main reason for selecting Apache Derby (The

Apache Software Foundation, 2017) was that it can be used in an embedded mode, which means

that it runs on the same Java Virtual Machine as the application. This simplifies testing as there is no

need to start up the database and deploy the application.

It was arranged for a representative from AccessPro Abseiling who deals with PPE records to be

involved in the evaluation of the product as it was being built. User-test sessions were planned at the

end of each increment to evaluate the completed parts of the system. There was a risk of the

representative not being available (see risk id 4 in Appendix 6: Risk Register). In such situations, an

attempt would be made to reschedule the session. As the last resort, the evaluation could be carried

out by the author who is also involved in PPE records management in the company.

Skills

The author studied modules such as M250 'Object-oriented Java programming', M256 'Software

development with Java' and TM354 'Software engineering'. As a result, the author had a relatively

good knowledge of plan-driven development, object-oriented analysis, design and implementation.

Therefore the risk of project failure associated with these skills was rather low (see risks id 8 and 9 in

Risk Register – Table A6.1, Appendix 6).

The author gained knowledge of Java EE 5 from studying M362 'Developing concurrent distributes

systems'. However, this project used Java EE 7 which added and updated some specifications.

Particularly, setting up of the development environment, JSF and testing using an embedded

database and embedded container were not covered in M362 and required additional research. This

posed a medium risk of project failure (see risk id 11 in Risk Register – Table A6.1, Appendix 6).

Lack of project management skills posed the biggest risk to the project (see risk id 16 in Risk Register

– Table A6.1, Appendix 6). Some aspects of project management were covered in TT284 'Web

technologies'. However, accurate time estimation requires experience and thus there was a high risk

that the project schedule was unrealistic. The contingency plan for this risk was to adjust the scope

of the project depending on the progress.

10


2 The project work

2.1 Literature

The literature presented in this section had a substantial impact either on the way the project was

conducted or on the way the product was developed. The information sources were identified via

The Open University's library, recommendations from the university tutors and the internet. The

research was focused on project management, software development and technology rather than

the problem domain. The quality of each information source was assessed before it was accepted for

this project. This involved ensuring that its content was relevant to the project, that the author was

an expert in the subject and that it was a reasonably recent publication. Table A7.1 in Appendix 7

contains an assessment of the credibility of the information sources presented in this section.

2.1.1 Project management

'Project planning and risk management' chapter of Dawson's Projects in Computing and Information

Systems (Dawson, 2015), describes planning a project and managing associated risks. Section 4.4

'Risk management' deals with identifying, assessing, alleviating and controlling risks. When creating

risk registers, identification of risks and their impact is not enough. In order to manage risks, there

needs to be a way to identify the most critical risks. Dawson describes two ways of categorising risks.

80/20 rule assumes that 20% of risks cause 80% of problems. This simple solution may not be

adequate for larger projects. The other solution is to use RAD grading (R – red, A – amber, G – green),

which splits risks to three groups depending on their ranking. RAD grading provides better

categorisation that is easy to read and thus it was used to create the risk register for this project (see

Appendix 6).

2.1.2 Software development

In 'Modelling Requirements: Use Cases' chapter of the Learning UML 2.0 (Miles and Hamilton, 2006)

Miles and Hamilton describe how use cases can be used to capture software requirements. Include

and extend are two common types of relationships between use cases. However, sometimes a use

case may have a number of different versions, which cannot be easily described using the include or

extend relations. Miles and Hamilton present use case generalisation relationship that is better

suited for these situations. They emphasise the fact that every step in the general use case must be

present in the specialised use case and every relationship between the general use case and other

use cases is inherited by the specialised use cases. The use case diagram for the PPE Management

System uses the generalisation relationship to show specialised versions of the view item of

11


equipment use case. This solution resulted in simpler diagram as the relationships that the

specialised use cases inherit from view item of equipment do not need to be shown explicitly (see

Figure A11.1 in Appendix 11).

2.1.3 Java EE and JSF

Extensive use of XML files can make configuration of Java EE difficult for inexperienced developers.

For example, database connections are specified in Persistence Unit in the persistence.xml file.

NetBeans can help with configuration by generating the necessary XML code. In the 'Interacting with

Databases through the Java Persistence API' chapter of Java EE 7 Development with NetBeans 8

Heffelfinger (2015) recommends using connection pools and data sources for database connections

to improve efficiency. He describes how to use NetBeans to specify a database connection using

connection pools and data sources. He does not, however, explain that this solution can only be used

when connections are managed by Enterprise JavaBeans (EJB) container.

Goncalves provides a more detailed explanation of when to use connection pools and data sources in

the chapter 'Managing Persistent Objects' of Beginning Java EE 7 (Goncalves, 2013d). He states that

data sources should be defined in a container-managed environment. In a situation where an

application manages database transactions itself, Persistence Unit should contain database

connection properties instead. In the 'Java Persistence API' chapter of the same publication

Goncalves (2013b) shows a complete persistence.xml file defining two separate Persistence

Units. One for connecting to a database running in the server mode and one for the embedded

mode. This solution was adopted in the project as it allowed both, testing entities without starting

the database, and deploying the application to GlassFish with the database running in the server

mode for user testing.

Furthermore, in the 'Callbacks, Timer Service, and Authorisation' chapter of Beginning Java EE 7,

Goncalves (2013f) shows how, in addition to Derby database running in the embedded mode, it is

possible to use an embedded Enterprise Java Bean (EJB) container. This feature, in combination with

the embedded database, allows testing EJBs without the need to start the database and application

server, making integration testing of EJBs much simpler. This project took advantage of this solution

enabling faster and easier integration testing of EquipmentItemEJB and ExaminationEJB (see

Appendix 17).

In the 'Object-relational mapping' chapter of Beginning Java EE 7, Goncalves (2013c) describes three

strategies provided by Java Persistence API (JPA) that can be used when mapping inheritance

relationship to a relational database. In the single-table-per-class hierarchy strategy the sum of all

attributes of all classes in a hierarchy is stored in one table. The advantage of this strategy is that it

does not require join operations to create instances of subclasses. However, its disadvantage is that

attributes of subclasses must be nullable. In the joined-subclass strategy each class is mapped to its

own table. This strategy provides good support for polymorphic queries where only root class is used

to create an object, but performance decreases when instances of subclasses are instantiated as join

operations are required. Finally, in the table-per-concrete-class strategy each concrete entity is

mapped to its own table with the attributes of the root class being mapped to columns in the

12


subclass table. As a result, instantiating subclasses does not require join operations but polymorphic

queries across hierarchy are less efficient. The analysis of the three strategies provided by Goncalves

led to the selection of the table-per-concrete-class strategy to implement the Inspector and

EmployedInspector classes. This was because the attributes of EmployedInspector could not be

nullable and creating instances of the subclass will be more common than polymorphic queries.

When implementing presentation tier of Java EE web application there was a choice of dynamic web

page generation technologies. In Beginning Java EE 7 Goncalves only presents JSF as this is the

preferred choice in Java EE 7. Although with less detail, Coward (2015) presents three different

technologies: Java Servlets, JavaServer Pages (JSP) and JavaServer Faces (JSF). He states that Java

Servlets are powerful as they give access to low-level web page generation mechanisms. The

disadvantage is the higher likelihood of errors. The biggest complaints about Java Servlets is that

HTML code is contained in Java statements, making it difficult to create the static content and that it

is not possible to separate presentation code from the code defining dynamic behaviour. Coward

describes how JSP attempts to solve the first problem by reversing the organisation of code. Finally,

he describes JSF, which he states 'is a better version of a JSP' (2015, p. 96). The main strengths of JSF

are web page components with a mechanism connecting them to application state, a web pages

navigation mechanism, and extensibility of the framework itself. Since the building of the PPE

Management System did not require access to low-level mechanisms of web page generation, JSF

was selected for implementation of the presentation layer.

In JSF versions 2.1 and earlier, web pages could only be created using JSF components. JSF 2.2

(available with Java EE 7) brought an ability to create web pages using HTML5 elements rather than

JSF components. In 'HTML5 and JSF' Juneau (2014) describes three ways to create web pages: using

JSF components only, using HTML5 elements only, and mixing both. The last solution was adopted in

this project. It allowed using HTML5 to create the static content of web pages and powerful JSF

components to generate the dynamic content from data stored in the system.

In the 'Processing and navigation' chapter of Beginning Java EE 7 Goncalves (2013h) describes how

Asynchronous JavaScript and XML (AJAX) can improve the responsiveness of a web application. In

normal HTTP communication a server sends an entire page as a response to client's request. AJAX

allows the server to send only the requested portion of data and the browser can then update the

required part of the web page. AJAX is natively supported in JSF since version 2.0 (available with Java

EE 6). Goncalves demonstrates two ways AJAX can be used in a JSF page. One solution uses the jsf.js

JavaScript library and requires manual coding of JavaScript for AJAX requests. A simpler way is to use

the <f:ajax> tag, which allows specification of the required behaviour declaratively without any

JavaScript coding. This project used the second approach to update lists of items of equipment

according to selected attributes and to display a list of defects as they are being added the system.

13


2.2 Developing the system

The development of the system was planned as a series of increments. The following subsections

describe in details objectives, content and outcomes of each increment.

2.2.1 Increment 1 – Equipment records

The objective of Increment 1 was to create a part of the system that would enable adding new

equipment records, viewing existing equipment records and deleting equipment records (FR1, FR2

and FR4 respectively in subsection 1.1.5).

Domain modelling

The author has already had an extensive knowledge of the problem domain gained working in the

rope access industry over a number of years. This meant that the author did not need to spend time

familiarising himself with the problem domain using interviews or other techniques. However, to

ensure that non-functional requirements NFR11 and NFR12 (see subsection 1.1.5) were satisfied, the

domain modelling phase of Increment 1 started with analysis of LOLER and ICOP, which were

described in more detail in subsection 1.1.1.

Following the analysis of the above documents, a list of business rules was compiled (see Appendix

8). Since LOLER covers all lifting equipment, it is applicable to PPE for work at height as well as to

lifting machinery such as cranes. ICOP is specific to the rope access industry but it covers a wide

range of subjects, not just PPE examination and maintenance. By compiling the list of business rules,

it was possible to capture in one place requirements that dictate the design of the system, e.g. what

information should be recorded, how long it should be kept for.

The business process of adding an item of equipment to the company's equipment pool was

analysed. A related UML activity diagram was created to capture the details of the process (see

Figure A9.1, Appendix 9).

The last task of domain modelling was to create the domain structural model and the glossary.

Objects in the problem domain that were relevant to the solution were identified using the

grammatical parse technique. After obtaining a list of candidate concepts for Increment 1 the

associations between them were identified and multiplicities specified. Finally, attributes were added

to the conceptual model. Figure A10.1 in Appendix 10 contains the domain structural model and

Table 10.1 contains the glossary.

The amount of work required to complete domain modelling, especially to create the domain

structural model, was underestimated. The task took 16 hours rather than planned 8 hours.

14


Requirements

High-level requirements of the entire system were specified in the Project planning phase (see

Appendix 2). The objective of the Requirements phase was to create system's use cases and detailed

software requirements. One way to elicit detailed functional requirements is to take each step in a

use case description and write down a corresponding software requirement (The Open University,

2014c).

In order to capture all functionality of the proposed software in one place, a complete use case

model covering the entire system was created (see Figure A11.1 in Appendix 11). One problem faced

during development of the use case model was how to show that searching for details of items of

equipment can be accomplished using different options, e.g. searching for an item with a given serial

number or searching for items of a given type. Creating separate use cases for each option would

result in an over-complicated diagram as viewing items of equipment is included in many other use

cases. As discussed in Subsection 2.1.2 the solution was to adopt the use case generalisation

concept. The view item of equipment with serial number, view item of equipment with examination

within next 28 days, and view item of equipment of given type use cases were presented as special

types of the general view item of equipment use case (see Figure 2.1 below).

Figure 2.1 A fragment of the use case diagram showing generalisation relationship between use

cases

Next, elaborated use case descriptions were created for the use cases covered in the current

iteration. These were UC1 add item of equipment, UC2 view item of equipment, UC2.1 view items of

equipment with serial number, UC2.2 view item of equipment of given type and UC3 remove item of

equipment. Table A11.1 in Appendix 11 contains a sample of elaborated use case description - UC1

add item of equipment. Elaborated use case descriptions were then used to elicit detailed functional

requirements. Appendix 12 contains a list of detailed functional requirements obtained from analysis

of UC1.

15


Analysis

In the Analysis phase, the domain structural model was transformed into the analysis structural

mode. The analysis classes represented future software classes rather than concepts in the problem

domain. Some constraints were added to the system. These were recorded in the glossary.

System operations were also specified for use cases considered in the current iteration. The system

operations were allocated to the EquipmentItemController backing bean that would deal with all

operations related to items of equipment.

Figure A13.1 in Appendix 13 contains the analysis structural model and Table A13.1 the analysis

glossary. Listing A13.2 contains a specification of the doAddItem() system operation.

Design

The design phase of object-oriented software development deals with assigning responsibilities to

classes, adding operation to classes to fulfil the responsibilities, and establishing navigability of

associations (The Open University, 2014d). The problem faced was that design of Java EE application

differs from general object-oriented design presented in the TM354 Software Engineering.

Responsibilities had to be assigned to specific framework components rather than to classes

representing domain concepts. Due to limited knowledge of Java EE framework, it was decided that

no design models would be created in Increment 1. Instead, design decisions would be made during

implementation of the system.

Implementation of the persistence layer

The implementation and testing phase started with setting up the development environment. Java

Standard Edition Java Development Kit 1.8, NetBeans package including NetBeans 8.2, Java EE 7

Software Development Kit, GlassFish Server 4.1.1, and Apache Derby 10.10.2.0 were installed on a

MacBook Pro running macOS Sierra (Version 10.12.3). A test of the development environment was

carried out using a sample application to discover GlassFish server failure. After a lengthy

investigation the problem was traced to proxy settings on macOS Sierra (bonnymwas, 2016).

The next task was to create a database for the system. Since it was built using object-oriented

approach, it was possible to use an object-relational mapping (ORM) tool to create a relational

database from Java entities rather than designing and implementing it. Goncalves (2013b)

recommends Java Persistence API (JPA) ORM tool, which is part of Java EE 7 and thus should be

supported in the future. The system uses EclipseLink ORM tool, which is the reference

implementation of JPA 2.1.

Following the advice given by Heffelfinger as described in Subsection 2.1.3, the initial version of the

Persistence Unit used a connection pool and a data source. This caused difficult to trace exceptions.

After a lengthy investigation the Persistence Unit for testing of entities was changed to define

database connection properties as described by Goncalves (2013b). Unfortunately, further errors

were encountered when attempting to clean and build project's files. After further investigation,

16


these errors were linked to inclusion of two Persistence Units in persistence.xml file, one to run

Derby database in the server mode and one to run it in the embedded mode. The solution adopted

was to comment out the Persistence Unit that was not required in a particular situation (see

Appendix 15).

With the database problems solved, the next step was implementation of the entities modelling

concepts from the problem domain. The following three entities were added: EquipmentItem,

Company and ConformityCertificate. As the entities were being implemented, appropriate tests were

written using JUnit framework. Although the project adopted test-driven development (TDD)

approach, it was not followed strictly. In TDD tests for a piece of code should be written before the

actual code. In practice, tests were written before or right after implementing a piece of

functionality. The important point is that the software was being tested more or less as it was being

written. Listing 16.1 in Appendix 16 contains the source code of EquipmentItem entity and Listing

16.2 contains its test class.

After implementing the entities, the database ij tool was used to inspect the database tables. Figure

2.2 below shows the EQUIPMENTITEM table structure. It can be seen that all attributes that

represent dates or a period of time were implemented using BLOB as the column type rather than

DATE. This is because the entity uses the new java.time classes available in JDK 1.8, which are not yet

supported by the current version of JPA. This problem was dealt with in Increment 2 (see subsection

'Implementation of the presentation layer' in Section 2.2.2).

Figure 2.2 EQUIPMENTITEM table structure

The final task of implementation of the persistence layer was to add queries to entities to enable

retrieving them from the database. JPA supports different type of queries. Named queries were

chosen for efficiency reasons (Goncalves, 2013d).

The amount of work required to implement entities, especially to write the required tests, was

underestimated. This, coupled with the problems described in this section, meant that the

Implementation phase has taken 25 hours, rather than the allocated 7 hours.

17


Implementation of business layer

The next task was to implement Enterprise JavaBeans (EJBs) which are server-side components that

encapsulate business logic and deal with many aspects of a web application such as transactions,

security, remote access, web services.

EquipmentItemEJB is a stateless session bean, which means that it does not preserve its state

between method calls and is thus more efficient than a stateful session bean (Goncalves, 2013e). It is

a facade for the EquipmentItem entity and handles create, read, update and delete (CRUD)

operations. Since the EJB is only accessed from components running in the web container in the

same Java virtual machine (JVM) (see the architecture diagram in Appendix 4) and all business

methods are accessible, the simplest solution was to expose no-interface view rather than defining a

local interface.

Another decision that had to be made was where in the system the links between associated classes

would be made. The EquipmentItem-Company link is made in the business layer because

EquipmentItemEJB needs to retrieve the Company entity from the database. However, as

EquipmentItem and ConformityCertificate are both instantiated in the presentation layer, it would be

possible to create a link between their instances either in the presentation layer or the business

layer. To ensure good maintainability of the system (see NRF9 and NRF10 in Appendix 2) it was

decided that all link manipulation operations would be performed by EJBs in the business layer.

Following the TDD approach, as EquipmentItemEJB was being written, so were its tests. Since EJB 3.1

(Java EE 6) standardised embedded containers, testing of EJBs became simpler as there is no need to

run the application server in a separate JVM process (Goncalves, 2013e). Nevertheless, developing

the EJB and suitable tests for all its methods was time-consuming and has taken 10 hours rather than

allocated 4 hours. Appendix 17 contains the source code of EquipmentItemEJB and its test class.

Implementation of the presentation layer

The presentation layer was implemented using JSF. It is a Model-View-Controller (MVC) framework,

which uses HTML pages as the view, backing beans/EJBs as the Model and FacesServlet as the

Controller. The servlet is an internal part of JSF and does not require any implementation, although

further configuration is possible via the faces-config.xml file (Goncalves, 2013g).

Most of the work on the presentation layer involved developing required web pages and the

EquipmentItemController backing bean for managing data and navigation between pages. The add-

item page was created first, followed by the backing bean and the view-items page. Initially, it was

planned to use HTML5 only but it quickly became apparent that some powerful JSF components

would speed up the development. The web pages were thus created using mix of HTML5 elements

and JSF components (see Section 2.1.3).

As more pages were developed, a need for a plan of navigation became apparent. Lieberman (2004)

suggests using UML Activity Diagrams for planning of a user interface navigation. This solution was

adopted in the project and Figure A18.1 in Appendix 18 contains the web pages navigation plan for

Increment 1.

18


A number of different scopes are available for backing beans. The request scope, where state is

maintained from the beginning of a request until the response is sent, was chosen for

EquipmentItemController to ensure low memory usage. As a result, when navigating between view-

item-details, remove-item and remove-item-confirmed pages it was necessary to pass the id attribute

of an item of equipment from page to page. Unfortunately, this requires multiple accesses to the

database in order to retrieve details of an item of equipment. The current solution may be changed

in the future to use a separate backing bean with the flow scope. It preserves state for the duration

of a specific sequence of interactions (Goncalves, 2013h).

In total six web pages, one backing bean and a LocalDate-String converter were developed. Appendix

19 contains the source code of the view-items page and EquipmentItemController backing bean.

Figures A20.1 to A20.7 in Appendix 20 contain screenshots of web pages supporting functional

requirements implemented in Increment 1.

As a result of relatively large amount of work using unfamiliar technology, development of the

presentation layer has taken 23 hours rather than planned 10 hours. The total time spent on the

implementation and testing phase was 58 hours, almost three times more than the planned 21 hours

(see Project Schedule in Figure A3.1 in Appendix 3).

Evaluation

In order to evaluate the product a user test session was held on the 5th May 2017. Requirements-

based tests were performed by a customer representative. The user carried out steps described in

use cases UC1 add item of equipment, UC2 view item of equipment, UC2.1 view item of equipment

with serial number, UC2.2 view item of equipment of given type, UC3 remove item of equipment,

looking at each use case in isolation. A test across use cases UC1, UC2 and UC3, was also performed.

Additionally, the complete use case model was reviewed for completeness. Section A21.1 of

Appendix 21 contains the plan of the session and the summary of findings.

The representative was generally satisfied with the product although relatively slow progress had to

be explained. Some new use cases were identified during the session. The system was planned to

allowed to view items of equipment with examination within one month. The requested functionality

was to allow to view items of equipment with overdue examination, view items of equipment that

will become obsolete within one month, and view items of equipment that have already became

obsolete. The system should also send email notifications if one or more items of equipment 'move'

into categories described above.

The representative pointed out that the system does not yet support adding used item of equipment.

He was informed that this feature (UC1.1 add used item) will be implemented at a later stage as it

depends on features that were not yet implemented. The representative also suggested adding more

attributes to the mechanism filtering displayed items of equipment.

19


Project plan and risk register review

On completion of Increment 1 the project plan was reviewed. The project was 3 weeks behind the

schedule and it was evident that most tasks were taking longer than estimated, with the

implementation and testing phase and TMA02 causing the most significant delays (see the initial

project schedule, Figure A3.1, Appendix 3). Even though it was expected that most of the problems

encountered in Increment 1 should not occur again in later increments, it was apparent that it would

not be possible to complete 3 increments within the available time. As a result, it was decided that

Increment 3, which was supposed to deal with security of the system, would be removed from the

scope of the TM470 project (see Section 1.1.5 for the requirements that were removed from the

scope of the project). Figure A3.2 in Appendix 3 shows a revised project schedule consisting of two

increments.

The risk register was also reviewed (see Table A6.2 in Appendix 6). No additional risks were

identified, but the likelihood of same risks was reduced. This was mainly a result of the knowledge

and experience gained in Increment 1 in areas such as project planning and Java EE.

2.2.2 Increment 2 – Recording and keeping track of examinations

The objective of Increment 2 was to create a part of the system that would enable adding new

examination reports, viewing existing examination reports, viewing items of equipment with

examination due within 1 month, and viewing items of equipment with overdue examination (FR5,

FR6, FR10 and FR11 respectively in subsection 1.1.5).

Domain modelling

The business rules identified in Increment 1 covered the entire system, thus no new business rules

were needed in Increment 2. A new business process – examine item of equipment – was identified

and an activity diagram created (see Figure A9.2, Appendix 9).

The grammatical parse technique was used again to identify concepts in the problem domain that

were relevant to the part of the system considered in Increment 2. Five new classes were identified:

Inspector, Examination, ExaminationReport, Defect and Repair. Appendix 10 contains the updated

domain structural model and glossary in Figure A10.2 and Table A10.2 respectively.

Requirements

The use case model created in Increment 1, was modified in response to client's feedback (see the

'Evaluation' subsection in Section 2.2.1). The updated model (see Figure A11.2 in Appendix 11)

contained new use cases: view item of equipment with overdue examination, view item of equipment

with date of obsolescence within a month, view item of equipment that is obsolete, view current

report and view past reports. Two existing use cases, view item of equipment with serial number and

20


view item of equipment of given type, were incorporated into the view item of equipment use case.

There are also four new use cases that are initiated by the system clock. Miles and Hamilton (2006)

suggest that even though system clock is actually a part of the system, modelling it as an actor helps

to show that the system must perform some tasks according to the current time.

Next, elaborated descriptions were prepared for the use cases covered in Increment 2. These were:

UC2.1 view item of equipment with examination within a month, UC2.2 view item of equipment with

overdue examination, UC4 record examination, UC5 create report, UC6 record defect, UC7 view

current report, UC8 view past reports. Table A11.2 in Appendix 11 contains description of the create

report use case. As opposed to Increment 1, it was decided not to elicit detail software requirements.

The reason was that the detailed requirements elicited in Increment 1 were not used during

subsequent development phases but required updating whenever use case description changed.

Analysis

In the analysis phase the analysis model, glossary, constraints and the specification of the system

operations were updated. Figure A13.2 in Appendix 13 contains the updated analysis structural

model and Table 13.2 contains the updated glossary.

It was identified that dateOfNextExamination and dateOfLastExamination attributes could be

implemented as derived attributes. It was however decided that only dateOfNextExamination would

be derived as this would enable automatic updating of this attribute when examinationInterval

changes. Making dateOfLastExamination a derived attribute would mean that every time a report

was retrieved it would be also necessary to retrieve the previous report.

A possible generalisation/specialisation relationship was also identified. Since only employed

inspectors have the employersName and employersAddress attributes, having EmployedInspector

specialising the Inspector entity would enable validation that all attributes are provided. In a solution

with a single entity representing both types of inspectors the additional attributes would have to be

nullable and thus simple validation would not be possible.

New constraints were added to the model. Some of them, such as not null or length of string, were

recorded in the glossary. Others, such as a constraint on when an item of equipment can be shown

as in use were recorded using Object Constraint Language (OCL). Listing A13.1 in Appendix 13

contains constraints on the EquipmentItem entity.

Finally, the following new system operations were specified: doViewItemsExam1Month(),

doViewItemsOverdueExam(), doRecordExamination(), doCreateReport() and doRecordDefect(). Listing

A13.3 in Appendix 13 contains the specification of the doCreateReport() system operation.

Design

In the design phase the design model and glossary were created and specifications of operations

were added. Figure A14.1 in Appendix 14 contains the design structural model and Table 14.1

contains the updated glossary.

21


ExaminationEJB that handles CRUD operations on Examination and its related entities was added.

recordExamination() and createReport() operations, which fulfil postconditions of the related main

system operations were specified. The navigation of associations was also established. Finally, the

use cases, design model, glossary and specification of operations were checked for completeness and

correctness.

Implementation of the persistence layer

The following five new entities were implemented: Examination, ExaminationReport, Defect,

Inspector, EmployedInspector and Repair. Additionally, two enumerated types were added:

DefectSeverity and ExaminationCategory.

At this stage, only basic constraints such as attribute values were implemented using Bean Validation

annotations. In general using a database for validation is not recommended as data needs to pass

through all application layers before it can be checked (Goncalves, 2013a). The only exception from

this was that JPA annotations were used to specify the maximum length of columns that store string

values.

As described in Section 2.1.3, the table-per-concrete-class inheritance mapping approach was used

when implementing the Inspector and EmployedInspector entities.

As the new entities were being developed not only their relevant tests were written and run

(integration testing) but also tests written in Increment 1 were re-run to check that the new entities

do not introduce any errors to the already implemented part of the system (regression testing).

Due to the amount of work required implementation of entities and their tests took 17 hours which

was significantly more than initially planned 10 hours.

Listing 16.3 in Appendix 16 contains the source code of the ExaminationReport entity and Listing 16.4

its tests class.

Implementation of business layer

The next task was to implement ExaminationEJB and its test class (see Listings A17.3 and A17.4

respectively in Appendix 17). Similarly to EquipmentItemEJB, ExamionationEJB is a stateless session

bean that handles operation of recording examination details and creating reports. These operations

can only be performed by an inspector, whose details are recorded. Once the security of the system

is implemented, this will be accomplished in the recordExamination method of ExaminationEJB

where the object representing the currently logged-in inspector will be retrieved and linked to the

Examination object. For now, this behaviour was simulated by retrieving an Inspector object from the

database (see Listing A17.3 in Appendix 17).

The initial design of ExaminationEJB specified a dedicated method for persisting Defect objects.

However, at the implementation stage, it was decided that rather than having a dedicated web page

for recording details of defects, a section of the create-report web page could be used for that

purpose. The backing bean would store Defect objects temporarily and AJAX would be used to

22


refresh the portion of the page displaying defects added so far. Once all the report's and defects'

details were entered the user would submit the form, which in turn would invoke the createReport

method of ExaminationEJB, where ExaminationReport and Defect objects would be persisted. As a

result persisting Defect objects is done implicitly (cascaded from persisting the ExaminationReport

object) in the createReport method and no dedicated method for persisting Defect objects was

required (see Listing A17.3 in Appendix 17).

Implementation of the presentation layer

The final stage of the implementation phase involved mainly development of the presentation layer

of the system, although, some problems with design of the system that became apparent at this

stage were also resolved.

First, ExaminationController backing bean was created for the new web pages (see Listing A19.3 in

Appendix 19). As a number of object of different classes had to be maintained for a duration longer

than a single request-response cycle the session scope was selected for the backing bean. The

problem with this solution was that objects were maintained even when new objects should have

been created. For example, once an examination had been recorded and an attempt was made to

record another examination, the backing bean used the previous Examination object. This resulted in

an error due to persisting the object that was already stored in the database. This will be resolved in

the future by introducing better control over lifecycle of objects. In order to lower the memory usage

the session scope may also be replaced with the flow scope, which maintains objects for a number of

specified pages.

The following 11 web pages were created to support the functionality added in Increment 2: create-

report, create-report-confirmed, dashboard, examination-one-month, overdue-examination, record-

examination, record-examination-confirmed, select-item, select-past-examination-report, view-

current-examination-report, view-past-examination-report. Listing A19.4 in Appendix 19 contains the

create-report page as a sample. Figures A20.8 to A20.14 in Appendix 20 contain screenshots of some

of the above web pages. As in Increment 1, growing complexity of the system was managed using

UML Activity Diagram to plan navigation between pages (see Figure A18.2 in Appendix 18).

One of the problems encountered when working on web pages displaying examination reports was

how to ensure that additional attributes of EmployedInspector (subclass of Inspector) are displayed.

JSF can only access attributes that a given entity has so it cannot be used to check at runtime

whether the entity accessed is actually Inspector of EmployedInspector and display appropriate

attributes. The solution created by the author was to include an additional getter method in the

Examination entity for its inspector attribute. While the 'normal' getter method returns the value of

inspector of the Inspector class, the additional getter method checks if inspector is an instance of

EmployedInspector, and if so returns the value of inspector cast to the EmployedInspector class. As

getter methods are used by JSF to access objects bounded to JSF components, it was then possible to

use normal getter method to display attributes of Inspector in every case and the additional getter

method to display attributes of EmployedInspector when that was actually the class involved. Listing

A16.5 in Appendix 16 contains the Examination entity and Listing A19.5 in Appendix 19 contains the

view-current-examination-report page.

23


A number of problems were encountered when working on web pages displaying items of

equipment with overdue examination or with examination due within a month. As described in the

'Implementation of the persistence layer' subsection of the Section 2.2.1, all attributes of the

LocalDate and Period types were stored in the database as BLOB type. In order to implement date

related queries LocalDateAttributeConverter and PeriodAttributeConverter had to be implemented.

As a result, LocalDate attributes were now stored in the database as DATE type and Period attributes

as VARCHAR type, as shown in Figure 2.3 below.

Figure 2.3 EQUIPMENTITEM table structure

As described in the 'Analysis' subsection above, dateOfNextExamination attribute in

ExaminationReport was implemented as a derived attribute so that its value would be automatically

updated when examinationInterval of the linked EquipmentItem object changes. However, deriving

dateOfNextExamination using a calculation also meant that querying the database for objects with

overdue examination or examinations due within certain time also required similar calculation.

Unfortunately, JPQL used in Java EE for database queries does not support date arithmetics. One

possibility was to use native queries with Structured Query Language (SQL), but date arithmetics are

handled differently in various databases (Tolpeko, 2012) and thus such solution would not be

portable across databases. As a result, a decision was taken to change implementation of

dateOfNextExamination to a normal attribute that would be stored in the database, enabling

appropriate queries to be written. Furthermore, it was also noted that as examination reports need

to be stored in unchanged form for a specified period of time, dateOfNextExamination in

ExaminationReport should not be altered when examinationInterval of EquipmentItem changes. As a

result, another dateOfNextExamination attribute was also added to EquipmentItem to enable

tracking and updating examination schedule, while dateOfNextExamination in ExaminationReport is

only used to store examination report data and will not be altered.

Relatively large number of web pages required, investigations of possible solutions to problems

described above and finally changes necessary in the already implemented part of the system and

24


the relevant tests resulted in implementation of the presentation layer taking 33 hours rather than

planned 15 hours.

Evaluation

In order to evaluate the part of the system built in Increment 2 a user test session was held on the

18th August 2017. A customer representative carried out steps described in use cases UC2.1 view

items of equipment with examination within one month, UC2.2 view items of equipment with

overdue examination, UC4 record examination, UC5 create report, UC6 record defect, UC7 view

current report, UC8 view past report. Tests across use cases UC1 add item, UC4, UC5, UC6, UC7 and

UC8 were also performed. The updated use case model was also reviewed with the client. Section

A21.2 of Appendix 21 contains the plan of the session and the summary of findings.

The representative was satisfied with the development of the system but acknowledged that it will

take some time for the system to become operational. When discussing the use case model, the

client suggested that the system should also allow supervisors and managers to record defects if

discovered between examinations. One of the issues highlighted by the representative after

executing UC2.1 and UC2.2 was that viewing of items with examination overdue or due within one

month does not incorporate filtering mechanism used elsewhere in the system. Also when selecting

an item of equipment to create examination report, (UC4), it is not possible to show only the items

with examination overdue or due within one month. A possible solution could be to incorporate

viewing items with examination overdue or due within one month into the filtering mechanism. The

representative also highlighted issues with the navigation between web pages, specifically that it is

not possible to go back to display lists of items with examination overdue or due within one month

after viewing details of one such item. Finally, it was noted that currently the system allows to view

items with overdue examination but it does not change their status to 'not in use'. It was confirmed

that this will be dealt when working on a notification mechanism.

25


2.3 Legal, social, ethical and professional issues

The product built in this project and the process of building it had to fulfil certain requirements.

These came from relevant legislations governing the problem domain, social and ethical

considerations, and professional code of conduct.

2.3.1 Legal issues

The Regulations that had the biggest impact on the product are The Lifting Operations and Lifting

Equipment Regulations 1998. They govern the use of all lifting equipment, from cranes to PPE for

work at height. These regulations directly influenced the design of the PPE Management System as

some of them were translated into business rules used to develop the solution. Incorrect

interpretation of the regulations, mistakes in the design process or errors in the implementation

could result in PPE missing the required examinations. Consequences could range from the rope

access company not being able to proceed with work due to lack of required examination reports, to

accidents and legal actions against the rope access company and the software developer. As a result,

a thorough testing of the software system is required before it can be put in use.

Another document, which although not a legal requirement, is still crucial to how rope access

companies operate, is IRATA International code of practice for industrial rope access (ICOP). As with

LOLER, requirements related to PPE inspection and information keeping contained in ICOP were

captured in the business rules.

PPE Management System will store data about users of PPE, supervisors, inspectors and managers.

As a result, the design of the system had to take into consideration data protection principles of the

Data Protection Act 1998. These require that personal data is used lawfully and only for the specific

purpose, is kept accurate and only for as long as necessary. The principle that had the biggest impact

on the product requires that personal data is protected from unauthorised access or processing, and

accidental loss or damage (Great Britain. Data Protection Act 1998). To ensure that these

requirements are satisfied Java EE security features will be used to authenticate users and authorise

access to different parts of the system. Data replication will be used to prevent accidental loss or

damage of data.

2.3.2 Social issues

Social issues are problems that affect a considerable amount of people rather than individuals.

Although rope access industry has very good safety records (IRATA, 2016) abseiling it is generally

perceived as a dangerous activity and thus often may be considered a last resort solution. The

primary purpose of the proposed system is to improve the way PPE records are maintained and

26


examinations are scheduled and thus raise safety standards. This, in turn, may have an impact on

how the industry is perceived as a whole, especially if this or similar systems are adopted by other

companies.

2.3.3 Ethical issues

A stakeholder impact analysis was completed in order to ensure that the project is carried out in an

ethical manner (see Appendix 22). The results of the analysis were already discussed in Section 1.1.4.

A conflict of interest existed with the development of the product for AccessPro Abseiling as part of

this project. This is because the author is also a co-owner of the rope access company. As a result,

there is a possibility of the client agreeing to accept a product that is below satisfactory standards.

This issue is partially addressed by conducting user tests.

2.3.4 Professional issues

When conducting this project the author acted in accordance with BSC Code of Conduct (British

Computer Society, 2017). As a result, the author has acknowledged that a conflict of interests

described in the previous subsection existed.

All techniques, technologies and tools used by the author to conduct the project are widely used

within the computing industry and to the best of the author's knowledge were appropriate to the

context. However, the author recognises that his expertise was gained from studying university

modules and he has no professional experience. The author lacked some of the skills required to

build the product and part of the project was to acquire them. This may have resulted in the product

not being developed to a satisfactory standard, with a possibility of undetected errors or security

issues. An independent assessment of the product should be sought before it is used.

All software products used to conduct the project, develop the product and used within the product

were available under open source licences. The author thus had right to use them. The author did

not use any personal or company's data thus no permissions were required.

The time available for the TM470 project was insufficient to build a complete product. Only some

parts of the system were developed within the project's scope. The remaining requirements will be

implemented in due course.

27


3 Review and reflection

3.1 Review of progress of project work

Regular progress reviews were performed throughout the duration of the project. These were

normally conducted at each Tutor-marked assignment (TMA) point, on completion of Increment 1

and at the end of the project. The following sections contain summaries of these reviews.

3.1.1 Review at TMA01

The main problem experienced so far was that project tasks were taking longer than estimated. For

example, domain modelling took 16 hours instead of planned 8 hours. The reason for such a

discrepancy was that with the existing knowledge of the problem domain, the author assumed that

creating the domain model would be a relatively quick process. In future projects, more time should

be allocated to this phase of development, especially if the author is not familiar with the problem

domain. Despite the described problem, the progress made at the beginning of the project was in

accordance with the plan (see Figure A3.1 in Appendix 3), and thus no change to the project scope

was required.


The project work was progressing at a slower pace than anticipated. Delays occurred due to

problems with setting up the development environment and establishing a database connection (see

'Implementation of persistence layer' in Section 2.2.1). Although this kind of problems was

anticipated (see Risk register, Table A6.1 in Appendix 6), they still caused a significant delay. In future

projects involving unfamiliar technology extra time should be allocated for solving technology related

problems or ensure that expert advice is available.

Another delay occurred due to TMA01 not being of a satisfactory standard. Following tutor's

feedback, almost all of the material from TMA01 had to be re-written. This resulted in the

preparation of TMA02 taking 46 hours instead of the planned 20 hours (see project plan in Figure

A3.1 in Appendix 3).

At TMA02 the project was approximately 2 weeks behind the schedule. A revision of the project plan

and scope was expected but left until completion of Increment 1.

28


3.1.3 Review at completion of Increment 1

The review at the end of Increment 1 (see 'Project plan review' in Section 2.2.1) showed that the

project was 3 weeks behind the schedule. In addition to the problems described above, further

delays occurred mainly due to a significant amount of work required in the implementation phase

(see Section 2.2.1) which took 58 hours rather than planned 21 hours.

The implemented part of the system satisfied functional requirements FR1, FR2, FR4 and non-

functional requirements NFR1, NFR5, NFR6, NFR9, NFR10, NFR11, NFR12 (see subsection 'Initial

scope of the project' in Section 1.1.5).

Due to the significant delay, a decision was taken to reduce the number of increments from 3 to 2

and remove some of the system requirements from the scope of this project (see the subsection

'Scope after Increment 1 review' in Section 1.1.5). Figure A3.2 in Appendix 3 shows updated project

schedule which reflects the changes.


Following the review of the project plan after completion of Increment 1 the work was progressing

more in line with the new plan (see project schedule in Figure A3.2 in Appendix 3). The experience

gained in Increment 1 was probably the main factor. Also, more time was allocated to some of the

tasks (Analysis and TMA03) and one task was left out (elicitation of detailed software requirements).

This does not mean that Increment 2 did not present any challenges. Main difficulties came from the

growing complexity of the system, with a number of decisions to be made about the design of the

system, e.g. use of generalisation/specialisation relationships or derived attributes.

At TMA03 the project was 1 week behind the schedule. This was due to TMA03 taking 47 hours

rather than planned 30 hours as the author decided to spend more time on preparing the draft of

the final report.

3.1.5 Final review

The implementation phase of Increment 2 took 60 hours rather than planned 35 hours. The main

factors that affected the progress were the amount of work involved, investigations of possible

design choices and changes required due to incorrect design decisions (see Section 2.2.2 for more

details). For the future projects more time should be allocated to implementation activities, with

special consideration to testing, which can be more time consuming than writing of actual software.

Despite the additional time required to complete the implementation, the project was only 15 hours

behind its schedule at the end of Increment 2. This was because the author reserved weeks 25 and

26 for family commitments but in the end was able to continue with the project work (see project

29


schedule in Figure A3.2 in Appendix 3). The 15 hours delay was not an issue as additional time spent

on earlier TMAs meant that a draft version of the final report was already written. As a result, it was

possible to use some of the time reserved for writing of the report to complete the development

work.

The system developed in Increments 1 and 2 satisfied functional requirements FR1, FR2, FR4, FR5,

FR6, FR10 and FR11, and non-functional requirements NFR1, NFR5, NFR6, NFR9, NFR10, NFR11,

NFR12 (see the subsection 'Initial scope of the project' in Section 1.1.5). The non-functional

requirements NFR13, NFR16 and NFR17 were not implemented due to delays in progress of the

project. It should also be acknowledged that the completed part of the system still requires further

work, such as implementation of validation and styling of the web pages.

The system will be developed further beyond the TM470 project to implement all requirements

specified in Appendix 2. The timescale for completion of the system has not been specified at this

stage.

30


3.2. Project management review

3.2.1 Review of life cycle model

The intention of the author was to use the incremental lifecycle model, where a product is built in a

series of increments. However as the number of increments was reduced from 3 to 2, it would more

accurate to describe the approach as a two-stage development rather than truly incremental.

Nevertheless, the principles of the incremental approach, such as dividing development into stages

and decomposing the product to smaller parts were still applied.

The approach taken was a suitable choice for this project. Its biggest advantage was that it reduced

the complexity of the entire system and allowed to deal with smaller parts of the problem, that were

more manageable for a single developer. This was especially important in Increment 1 when majority

of problems occurred. It would be more difficult to solve them if the complexity of the entire system

had to be dealt with at the same time.

3.2.2. Review of project schedule

Initially, the project schedule was created in a form of a detailed breakdown of tasks and subtasks

(see Table A3.1 in Appendix 3). Following an advice from the tutor, a Gantt chart version of the

project schedule was also created (see Figure A3.1 in Appendix 3). A project journal was also

maintained to record details of work sessions (see Appendix 23).

The tutor's advice proved beneficial to the project as the Gantt chart version of the schedule was

found useful for monitoring progress and easy to update when required. The detailed version of the

schedule was useful for checking tasks breakdown for a given week but it did not allow to easily

monitor the progress of the project. It was also difficult to update. As a result, it was decided to stop

using the detailed version of the schedule. The Gantt chart was used for planning and monitoring

progress. Recording in the project journal was then modified in order to use it as a weekly planning

tool. This system worked well for the remaining part of the project and should be adopted in future.

3.2.3 Review of risk register

The system used to identify, assess and control risks also performed well (see Section 2.1.1 and Table

A6.1 in Appendix 6). It clearly identified the most critical risks, enabling implementation of control

measures. One of the two biggest risks was that the project planning estimates were unrealistic. This

turned out to be true and was dealt with by reviewing the project scope. Family events were another

significant risk to the project and were dealt with by incorporating them into the schedule.

31


It was also relatively easy to update the risk register following the review at the end of Increment 1

(see 'Project plan and risk register review' in Section 2.2.1 and Table A6.2 in Appendix 6)

3.2.4 Review of working with tutor

Communication with the tutor was maintained throughout the project to enable him to monitor the

progress and comment on various aspects of the project. Appendix 24 contains a sample of a

progress report and a record of all communication with the tutor is in Table A24.1. The most

important support from the tutor was feedback to the TMAs. It was used to compile lists of

improvements required in subsequent versions of the report.

32


3.3 Literature, resources and methods review

3.3.1 Review of literature

All initially selected sources of information were valuable to the project, however, some were used

more than others. Beginning Java EE 7 by Goncalves was the most important source of information

on the technical aspects of the project. Its very detailed description of Java EE guided the

development of the output of the project and useful examples helped to solve problems

encountered (see Sections 2.1.3, 2.2.1 and 2.2.2). His expert knowledge and years of involvement in

Java community (see Credibility assessment of information sources in Appendix 7) resulted in

creation of the high standard publication that can be recommended for any project involving Java EE.

The reason for adding Heffelfinger's Java EE 7 Development with NetBeans 8 to the literature was to

learn how to effectively use NetBeans for Java EE development. To that extend the source was useful,

showing how to set up a project and add various components. It does not, however, explain Java EE

in detail. This resulted in problems with specification of the persistence unit described in the

'Implementation of the persistence layer' subsection of Section 2.2.1.

Other publications contributed to specific areas of the project such as project management, selection

of presentation technology or UML. However, the initially selected information sources did not

contain enough information to solve all encountered problems and other sources were consulted to

find solutions. For example, the problem with running Glassfish Server on macOS Sierra was solved

by consulting NetBeans bug reports (see the 'Implementation of the persistence layer' subsection of

Section 2.2.1).

3.3.2 Review of resources

The selected resources proved appropriate and sufficient to the project as all were successfully used

to develop its output and no additional resources were required.

Java EE is a powerful platform that evolved over the years to cater for building large enterprise

systems. As a result, the complexity of the platform itself grew and may be overwhelming for

inexperienced developers. Fortunately, improvements in the recent versions of Java EE made

development simpler and faster. The main components of the platform such as entities, EJBs and

backing beans, are implemented as POJOs with appropriate annotations. The 'configuration by

exception' concept, used throughout Java EE platform, simplifies and speeds up development

process as the default configuration is applied unless specified otherwise.

Implementation of web-based presentation layer was a complex task on its own. It involved a

significant amount of effort to create a number of web pages and organise data transfer between

them and the system. JSF made this task manageable. Synchronisation of data was relatively easy to

implement with backing beans. They also allowed for simple specification of navigation between

33


pages. Powerful JSF components handled dynamic web pages generation and built-in AJAX support

allowed to create more efficient and user-friendly solution.

GlassFish Server is a complex tool. Many problems in this project were encountered when

attempting to deploy the application on GlassFish. This often resulted in a long stack of exceptions

being displayed. Fortunately, Java EE has a large development community and it was always possible

to find a solution on the internet.

An important advantage of Java EE is its support for testing. Integration testing of entities and EJBs

was easily performed without the need to start the database and the application server thanks to

embedded database and container.

3.3.3 Review of methods

Methods selected for the project worked well. Plan-driven development allowed to create a design

of the system before starting implementation. This was beneficial as it clearly separated different

aspects of software development to relevant phases. In Increment 1 modelling was stopped at the

analysis phase because assigning responsibilities to various components of the Java EE required

better knowledge of the platform. In Increment 2 the design model was developed. The approach

taken allowed for some flexibility in following the plan-driven development. For example, as detailed

functional requirements produced in Increment 1 were not useful to the project, they were not

created in Increment 2.

TDD was used to develop entities and EJBs. Although not followed strictly, as tests were written

either before or after a piece of code, it allowed to spread testing throughout the development

process rather than leaving it to the end. With the large number of errors encountered it would be

very difficult, if not impossible, to deal with them if they were left to the end of an increment or the

project. TDD allowed correcting them one at the time, soon after they were introduced. The use of

JUnit testing framework facilitated integration and regression testing. The presentation layer was

tested by running the application and performing steps in the relevant use cases.

34


3.4 Skills development review

3.4.1 Technical skills

The majority of new skills were related to Java EE, expanding the knowledge gained from studying

M362 'Developing concurrent distributes systems'. The author has learned how to set up Java EE

development environment and establishing a connection to a database working in different modes.

The knowledge of JPA was expanded, including specification of more complex object-relational

mapping such as inheritance mapping, and retrieving entities using JPQL. The author has learned

how a database working in the embedded mode and embedded container can facilitate integration

testing of entities and EJBs. Finally, the author has learned how JSF technology can be used to

implement the presentation layer of a software system.

In addition to Java EE, the author expanded his knowledge of UML by learning about generalisation

relationship between use cases. An experience of designing a database driven system was also

gained. The author noted differences between a general object-oriented design, where

implementation of attributes and associations as derived may be beneficial, and design of database-

driven systems, where attributes often need to be implemented as variables so that appropriate

queries could be written.

Beginning Java EE 7 by Goncalves, which was the main source of technical knowledge, helped the

author gain a general understanding of the Java EE platform. For the future development of the PPE

Management System the author plans to use publications dedicated entirely to specific areas such as

building the persistence layer with JPA, implementation of the business layer with EJBs, creating the

presentation layer with JSF and security.

3.4.2 Project management skills

With little prior experience of project management, this project provided opportunity to learn new

skills in that area. Management of this project can be divided to three distinctive phases: planning,

monitoring and reviewing.

The author spent the first week of the project on planning activities. As in previous projects, the

author created a detailed project plan. Following the tutor's advice the author learnt about Gantt

charts and created one for the project (see Figures A3.1 in Appendix 3). Since the author has never

developed a substantial software system, estimating the timescale of project tasks proved difficult.

Another aspect of planning was to create the risk register. The author researched different methods

of identification of the most critical risks and decided to use the RAD grading method (see Section

2.2.1).

Following the planning phase, the next important aspect of project management was monitoring the

project. The main activity was monitoring the progress of the project. The author learnt how to use

35


Gantt chart to record and monitor progress and discovered that it is a much better tool for this

purpose than the detailed project plan created earlier.

As number of reviews took place during the project, the Gantt chart was used to compare the

planned and actual tasks times and identification of tasks that took significantly more time than

allocated. The experience gained allowed for better estimation of tasks times in Increment 2.

3.4.3 Personal development

The author has learned more about his own abilities. Most of the project work was carried out at

night time. This was not an issue for practical tasks. However, the author observed that efficiency in

report writing deteriorated at night. As a result, an effort has been made to allocate more day time

for this task.

Finally, the author has gained or improved general skills required to conduct an academic project.

These include preparation of a project proposal, conducting a literature search, maintaining a project

journal, evaluating his own work and report writing.

(12,715 words)

36


References

bonnymwas (2016) 'Bug 268076 - Unable to start GlassFish 4.1 on macOS Sierra (Version 10.12)'

forum message to NetBeans Bugzilla, 27 September [Online]. Available at

https://netbeans.org/bugzilla/show_bug.cgi?id=268076 (Accessed 13 March 2017).

British Computer Society (2017) BCS Code of Conduct [Online]. Available at

http://www.bcs.org/category/6030 (Accessed 30 June 2017).

Coward, D. (2015) Java EE 7 The Big Picture, Oracle Press.

Data Protection Act 1998. Chapter 29 (1998). The Stationery Office [Online]. Available at

http://www.legislation.gov.uk/ukpga/1998/29/contents (Accessed 9 April 2017).

Dawson, C. (2015) 'Project planning and risk management', in Dawson, C. Projects in Computing and

Information Systems, Pearson, pp. 62-89.

Deitel, P. and Deitel, H. (2015) 'Introduction to Computers, the Internet and Java', in Deitel, P. and

Deitel, H. Java How to Program, Pearson, pp. 43-75.

Goncalves, A. (2013a) 'Bean Validation', in Goncalves, A. Beginning Java EE 7, Apress, pp. 67–101.

Goncalves, A. (2013b) 'Java Persistence API', in Goncalves, A. Beginning Java EE 7, Apress, pp. 103–

124.

Goncalves, A. (2013c) 'Object-Relational Mapping', in Goncalves, A. Beginning Java EE 7, Apress, pp.

125–176.

Goncalves, A. (2013d) 'Managing Persistent Objects', in Goncalves, A. Beginning Java EE 7, Apress,

pp. 177–226.

Goncalves, A. (2013e) 'Enterprise JavaBeans', in Goncalves, A. Beginning Java EE 7, Apress, pp. 227-

261.

Goncalves, A. (2013f) 'Callbacks, Timer Service, and Authorisation', in Goncalves, A. Beginning Java

EE 7, Apress, pp. 263-288.

Goncalves, A. (2013g) 'JavaServer Faces', in Goncalves, A. Beginning Java EE 7, Apress, pp. 305-348.

Goncalves, A. (2013h) 'Processing and navigation', in Goncalves, A. Beginning Java EE 7, Apress, pp.

349-385.

Heffelfinger, D. (2015) 'Interacting with Databases through the Java Persistence API', in Heffelfinger,

D. Java EE 7 Development with NetBeans 8, Packt Publishing, pp. 131-174.

IRATA International (2014) IRATA International code of practice for industrial rope access, IRATA

International.

37


IRATA International (2016) Work and Safety Analysis 2016 [Online], Ashford, IRATA International.

Available at https://irata.org/downloads/2054 (Accessed 31 August 2017).

Juneau, Josh (2014) 'HTML5 and JSF', Oracle Technology Network [Online]. Available at

http://www.oracle.com/technetwork/articles/java/enterprise-html5-2227136.html (Accessed 18

June 2017).

Lieberman, Benjamin (2004) 'UML Activity Diagrams: Detailing User Interface Navigation', IBM –

developerWorks [Online]. Available at

https://www.ibm.com/developerworks/rational/library/4697.html (Accessed 22 June 2017).

The Lifting Operations and Lifting Equipment Regulations 1998 (1998) [Online]. Available at

http://www.legislation.gov.uk/uksi/1998/2307/made/data.pdf (Accessed 22 February 2017).

Miles, R. and Hamilton, K. (2006) 'Chapter 2: Modelling Requirements: Use Cases' in Miles, R. and Hamilton, K. Learning UML 2.0, Sebastopol, O'Reilly Media, pp. 43 – 62.

Red Hat (2017a) 'Hibernate OGM', Hibernate [Online]. Available at http://hibernate.org/ogm/ (Accessed 14 June 2017).

The Open University (2014a) 'An introduction to software development', in The Open University TM354 Block 1 Units 1 Approaches to software development, Milton Keynes, The Open University, pp. 28-47.

The Open University (2014b) 'Activities and artefacts in the development process', in The Open

University TM354 Block 1 Units 1 Approaches to software development, Milton Keynes, The Open

University, pp. 56-62.

The Open University (2014c) 'Functional requirements', in The Open University TM354 Block 1 Units

2 Requirements concept, Milton Keynes, The Open University, pp. 82-92.

The Open University (2014d) 'Design – assigning responsibilities', in The Open University TM354

Block 2 Unit 8 The case study: part 2, Milton Keynes, The Open University, pp. 226-242.

Tolpeko, D. (2012) 'PostgreSQL - DATEADD - Add Interval to Datetime', SQLines [Online]. Available at

http://www.sqlines.com/postgresql/how-to/dateadd (Accessed 12 August 2017).

38


Software Resources

The Apache Software Foundation (2017) Apache Derby (Version 10.10.2.0) [Computer program].

Available at http://db.apache.org/derby/index.html (Accessed 14 June 2017).

Eclipse Foundation (2017) Eclipse IDE (Version Neon 3) [Computer program]. Available at

https://www.eclipse.org (Accessed 13 June 2017).

JetBrains (2017) IntelliJ IDEA (Version 2017.1.4) [Computer program]. Available at

https://www.jetbrains.com/idea/ (Accessed 14 June 2017).

Meteor Development Group (2017) Meteor (Version 1.5) [Computer program]. Available at

https://www.meteor.com (Accessed 13 June 2017).

Microsoft (2017) .Net (Version 4.7) [Computer program]. Available at

https://www.microsoft.com/net/ (Accessed 13 June 2017).

MongoDB (2017) MongoDB (Version 3.4) [Computer program]. Available at

https://www.mongodb.com/what-is-mongodb (Accessed 14 June 2017).

Oracle (2015) GlassFish (Version 4.1.1) [Computer program]. Available at

https://javaee.github.io/glassfish/ (Accessed 14 June 2017).

Oracle (2017a) Java EE 7 SDK (Version 7, Update 3) [Computer program]. Available at

http://www.oracle.com/technetwork/java/javaee/downloads/index.html (Accessed 13 June 2017).

Oracle (2017b) Netbeans IDE (Version 8.2) [Computer program]. Available at https://netbeans.org

(Accessed 13 June 2017).

Oracle (2017c) MySQL Community Edition (Version 5.7.18) [Computer program]. Available at

https://www.mysql.com/products/community/ (Accessed 14 June 2017).

The PostgreSQL Global Development Group (2017) PostgreSQL (Version 9.6.3) [Computer program].

Available at https://www.postgresql.org (Accessed 14 June 2017).

Red Hat (2017b) Red Hat JBoss Enterprise Application Platform (Version 7) [Computer program].

Available at https://developers.redhat.com/products/eap/overview/ (Accessed 14 June 2017).

39


Bibliography

Great Britain. The Work at Height Regulations 2005 (2005) [Online]. Available at (Accessed 22

February 2017).

Health and Safety Executive (2014) Safe use of lifting equipment [Online]. Available at

http://www.hse.gov.uk/pUbns/priced/l113.pdf (Accessed 22 February 2017).

40

Appendix 1: Examination report

Figure A1.1 A sample examination report for multiple items of PPE currently used in AccessPro Abseiling

41

Appendix 2: Requirements of PPE Management System

Functional requirements

FR1: The system will permit a new equipment record to be added to a database.

FR2: The system will permit an existing equipment record to be viewed.

FR3: The system will permit an existing equipment record to be amended.

FR4: The system will permit an existing equipment record to be deleted.

FR5: The system will permit a new examination report to be added to a database.

FR6: The system will permit an existing examination report to be viewed.

FR7: The system will permit an existing examination report to be amended.

FR8: The system will permit an existing examination report to be deleted.

FR9: The system will remove an examination report from the database after a specified period of

time.

FR10: The system will notify users when an item of equipment is due for examination within 1

month.

FR11: The system will notify users when examination of an item of equipment is overdue.

FR12: The system will notify users when an item of equipment will reach the end of its lifespan

within 1 month.

FR13: The system will notify users when an item of equipment reached the end of its lifespan.

FR14: The system will permit a new inspection record to be added to a database.

FR15: The system will permit an existing inspection record to be viewed.

FR16: The system will permit an existing inspection record to be amended.

FR17: The system will permit an existing inspection record to be deleted.

FR18: The system will remove an existing inspection record when the record of the related

equipment item is deleted.

FR19: The system will permit a new repair record to be added to a database.

FR20: The system will permit an existing repair record to be viewed.

FR21: The system will permit an existing repair record to be amended.

42

FR22: The system will permit an existing repair record to be deleted.

FR23: The system will permit a new examination scheme to be added to a database.

FR24: The system will permit an existing examination scheme to be viewed.

FR25: The system will permit an existing examination scheme to be amended.

FR26: The system will permit an existing examination scheme to be deleted.

FR27: The system will permit a new project record to be added to a database.

FR28: The system will permit an existing project record to be viewed.

FR29: The system will permit an existing project record to be amended.

FR30: The system will permit an existing project record to be deleted.

FR31: The system will permit allocation of equipment items to a project.

FR32: The system will permit allocation of equipment items to a technician.

FR33: The system will permit allocation of equipment items to a supervisor.

FR34: The system will permit recording of use of equipment.

FR35: The system will permit registration of a manager.

FR36: The system will permit registration of an inspector.

FR37: The system will permit registration of a supervisor.

FR38: The system will permit registration of a technician.

Non-functional requirements:

1. Operational and environmental requirements

NFR1: The system shall be accessible over the internet via a desktop/laptop web browser.

NFR2: The system shall be accessible over the internet via a tablet/mobile device web browser.

NFR3: It should be possible to deploy the system in cloud environment (Platform as a service).

2. Performance requirements

NFR4: The system shall operate without failure for 30 days.

NFR5: The system shall recover from failures without any data lose.

NFR6: The system shall support concurrent access from multiple users.

43

NFR7: The system shall respond to most user inputs within 2 seconds.

NFR8: The system shall respond to a complex user input within 5 seconds.

3. Maintainability and support requirements

NFR9: The system shall be able to be modified to cope with changes in functional and non-functional

requirements.

NFR10: The system shall be able to be modified to cope with new functional and non-function

requirements.

4. Legal requirements

NFR11: The system shall be compliant with The Lifting Operations and Lifting Equipment Regulations

1998.

NFR12: The system shall be compliant with IRATA International code of practice for industrial rope

access.

NFR13: The system shall be compliant with Data Protection Act 1998.

5. Look-and-feel requirements

NFR14: The system shall have uncluttered forms.

6. Usability and humanity requirements

NFR15: Users should be able to complete their tasks without any special training.

7. Security requirements

NFR16: System shall be accessible to registered users only.

NFR17: Registered users shall be able to access only the functionality allocated to their role within

the system.

44

Appendix 3: Project schedules

Table A3.1 A sample of detailed project schedule

Phases, TasksMilestones

Planned

Duration(Actual)

Planned

Week(Actual)

Planned

CompletionDate

Output

1. Concept Development

1.1 Email the tutor my project ideas 1 hour 1 (0) 6 Feb

1.2 Choose the project subject 1 hour 1 (0) 8 Feb

2. Planning

2.1 Working title, description and scope 2 hours(5) 1 (1) 8 Feb

2.2 Prepare major tasks and subtasks 4 hours(4) 1 (1) 9 Feb

2.3 Choose lifecycle model 2 hours(2) 1 (1) 10 Feb

2.4 Create the project's schedule 2 hours(2) 1 (1) 10 Feb Project Schedule

2.5 List resources, skills and methods 2 hours(2) 1 (1) 11 Feb

3. Research (4)

3.1 Complete a literature search on Java

EE7

0.5 hour 2 (2) 13 Feb

3.2 Analyse literature 1 hours 2 (2) 13 Feb

3.3 Compile a list of literature for

possible use in project

0.5 hour 2 (2) 13 Feb

3.4 Complete review of literature 1 hour 2 (2) 13 Feb Literature

Iteration 1: adding, viewing and

removing equipment records

4. Domain modelling

4.1 Compile a list of domain description

literature

0.5 hour (1) 2 (2) 14 Feb

4.2 Analyse literature 3 hours

(next)

2 (2) 14 Feb

4.3 Identify business rules 1 hour (5) 2 (2) 14 Feb Business rules

4.4 Identify business processes 2 hours (3) 2 (2) 15 Feb Activity diagrams

4.5 Create a domain structural model

and a glossary

1 hour (7) 2 (3) 15 Feb Domain structural

model and glossary

45

Figure A3.1 Initial project schedule used until completion of Increment 1 (week 13)

46

Figure A3.2 Project schedule updated as part of the review after completion of Increment 1 (week 13)

47

Appendix 4: System architecture

Figure A4.1 Three-layer architecture of the PPE Management System implemented using Java EE

48

Appendix 5: Analysis of lifecycle models

Table A5.1 Strengths and weaknesses of the main alternative lifecycle models

Lifecycle model Strengths Weaknesses

Waterfall - Easier planning of the project as

each phase of the lifecycle is visited

only once and changes are not

expected.

- The entire system have to be considered in

each phase of the project. With limited time

available for TM470 project delivering of

implementation would not be possible.

- The client cannot evaluate the system, and

add/change requirements until the end of

the development process.

Iterative The iterative lifecycle model does not

have any particular strengths in

comparison to the incremental model

in relation to this project.

- The entire system have to be considered in

each phase of the project. With limited time

available for TM470 project delivering of

implementation would not be possible.

Risk-driven - Good for prioritisation of system

features by assessing a risk of not

delivering a particular feature.

- Reduces chances of project failure in

a later stage by considering high

importance, hight risk features first.

- Using an unfamiliar lifecycle model in the

project would increase chances of project

failure.

49

Appendix 6: Risk registers

Table A6.1 The initial risk register for the PPE Management System project

50

Table A6.2 Risk register updated as part of the review after completion of Increment 1 (week 13)

51

Appendix 7: Assessment of credibility of information sources

Table A7.1 Assessment of credibility of the information sources presented in Section 2.1

Author Title

(publication year)

Assessment

Coward, D. Java EE 7 The Big

Picture

(2015)

Dr Danny Coward is a Principal Architect at Oracle. He contributed

to all editions of Java, leading definitions some of the platform's

APIs and started the Java FX project. He was an executive member

of Java Community Process. He holds a doctorate in Number

Theory from University of Oxford.

Rather than concentrating on selected elements of Java EE

platform, Java EE 7 The Big Picture encompasses the entire

platform. Although descriptions may be less detailed than in some

more selective books, this recent publication covers some subjects

omitted in other sources of information.

Dawson, C. Projects in

Computing and

Information

Systems

(2015)

Dr Christian Dawson is a senior lecturer in the Computer Science

department at Loughborough University. He co-authored many

journal articles and conference papers. He was also a tutor for a

number of Phd students.

However, Projects in Computing and Information Systems is aimed

at both, students undertaking a research degree and a taught

degree and thus its content should be suitable for this project. It is

also a recent publication.

Goncalves,

A.

Beginning Java EE

7

(2013)

Antonio Goncalves is a senior software architect and Java EE

consultant. He is involved with Java Community Process Program

as an Expert Member of various Java Specification Requests. He

wrote number of books on Java EE and gives talks on international

conferences. For his work for Java community, Goncalves has been

elected Java Champion. He has a MSc in Object-oriented design

from Brighton University and MPhil in Distributed Systems from

UFSCar University in Brazil.

Beginning Java EE is a reasonably recent publication containing a

very detailed description of version 7 of Java EE platform. Most of

the content was relevant to this project and thus the book was the

main source of information for the implementation phase of the

project lifecycle.

52

Heffelfiner,

D.

Java EE 7

Development with

NetBeans 8

(2015)

David Heffelfinger is the Chief Technology Officer at Ensode

Technology, a software consulting firm in the United States. He has

a MSc in software engineering from Southern Methodist University

in Dallas and published a number of books on Java.

Java EE 7 Development with NetBeans 8 is a recent publication

which presents how NetBeans can be used to develop Java EE

applications. It does not, however describe in detail Java EE

platform itself.

Juneau, J. HTML5 and JSF

(2014)

Josh Juneau is an application developer/system analyst at

Fermilab. He contributed to Java community for years, leading

various projects and advocating for Java EE 8. He wrote a number

of book about Java and Java EE and is a technical writer for Java

Magazine. For his work ha has been awarded Java Champion.

HTML5 and JSF is a reasonable recent article that originally

appeared in Java Magazine and is also available at Oracle

Technology Network website. It describes in detail how HTML5 can

be used to create JSF pages.

Miles, R.

and

Hamilton,

K.

Learning UML 2.0

(2006)

At the time of writing Learning UML 2.0 Russ Miles was a software

engineer for General Dynamics UK, where he specialised in Java

and distributed systems and was studying for MSc in software

engineering at Oxford University. Hamilton was a software

engineer at aerospace corporation and had MSc in applied math

and computer science from Cornell University.

While the content of Learning UML 2.0 is relevant to this project,

the book was published in 2006 and covers UML 2.0. The current

version of UML at the time of writing is 2.5 and thus some of the

information may be out of date. However, the author was unable

to find more recent publications other than the UML specification

published by Object Management Group.

53

Appendix 8: Business rules

Examination and inspection intervals

1. Every item of PPE put into service for the first time must examined unless either:

a) it has not been used before, and an EC declaration of conformity created not more than

12 months ago is available;

b) it has been used before, and is accompanied by examination report as required by

LOLER. (LOLER R9, P1)

2. Every item of PPE must be examined by a competent person:

a) at least every 6 months;

b) in accordance with an examination scheme drawn up by a competent person

(examination intervals may be longer or shorter than 6 months);

c) each time exception circumstances occur that could potentially lead to equipment being

damaged. (LOLER, R9, P3)

3. Every item of equipment may require interim inspections by a competent person (if required

by a risk assessment) at suitable intervals between examinations. (LOLER R9, P3)

Reports and defects

4. A person making an examination must:

a) notify a company's manager immediately of any defect in PPE that could be dangerous to

persons;

b) as soon as practicable (no longer than 28 days after the examination) make a written

report, authenticated by signature or equally secured means, to a company's manager,

and hiring company if applicable.

c) send a copy of the report to the relevant enforcing authority (HSE or local authority's

environmental health department) if there is a defect posing a risk of serious personal

injury. (LOLER R10, P1)

5. A person making an interim inspection must:

a) notify the employer immediately of any defect in the lifting equipment that could be

dangerous to persons;

b) as soon as practicable record the inspection in writing. (LOLER R10, P2)

6. A manager notified about defective equipment as a result of an examination must ensure

that the an item of PPE is not used before the defect can be rectified. If a time is given after

which the equipment will not be safe to use, the equipment must not be used after that

time. (LOLER R10, P3)

54

Keeping of information

7. An EC declaration of conformity received when obtaining lifting equipment must be kept for

as long as the equipment remain in use. (LOLER R11, P1)

8. Reports from examinations made before an item of PPE is put into service must be kept until

the equipment is no longer used. (LOLER R11, P2)

9. Reports from all other examinations must be kept until the next report is made or the

expiration of two years, whichever is later. (LOLER R11, P2)

10. Records of interim inspections must be kept available until the next such record is made.

(LOLER R11, P2)

Examination report

11. Information to be included in an examination report:

a) The name and address of the company for whom the examination was made. (LOLER

Schedule 1)

b) The address of premises at which the examination was carried out. (LOLER Schedule 1)

c) Details necessary to identify an item of PPE, e.g. serial number, date of manufacture.

(LOLER Schedule 1)

d) The safe working load (SWL), working load limit, maximum and minimum rated loads, if

the SWL depends on configuration, the last configuration in which the equipment was

examined. (LOLER Schedule 1)

e) Whether it was an examination:

before first use; (LOLER Schedule 1)

within an interval of 6 months; (LOLER Schedule 1)

in accordance with an examination scheme; (LOLER Schedule 1)

after exception circumstances occurred that could potentially lead to equipment

being damaged. (LOLER Schedule 1)

after use in an arduous environment (IRATA ICOP I.2)

f) Whether an item of PPE is safe to use. (LOLER Schedule 1)

g) Identification of any defective part, which is or could become danger to persons,

together with a defect description. (LOLER Schedule 1)

h) Details of any repairs/renewals/alternations required to remedy a defect. (LOLER

Schedule 1)

i) The time by which a defect could become a danger to persons, for defects which do not

pose danger to persons at the time of examination but may in the future. (LOLER

Schedule 1)

55

j) Instructions to technicians and supervisors to monitor a defect during pre-use checks for

defects which do not pose danger to persons at the time of examination but may in the

future. (IRATA ICOP I.2)

k) The date by which the next examination must be carried out. (LOLER Schedule 1)

l) The date of first use (IRATA ICOP I.2)

m) The date of the last examination. (IRATA ICOP I.2)

n) If applicable, details of any tests carried out as part of examination. (LOLER Schedule 1)

o) The date of the examination. (LOLER Schedule 1)

p) The name, address and qualifications of the inspector, whether self-employed or

employed, and if employed, the name and address of the employer. (LOLER Schedule 1)

q) The name and address of a person signing/authenticating the report on behalf of the

inspector. (LOLER Schedule 1)

r) The date of the report. (LOLER Schedule 1)

PPE records

12. Records tracking the use, examination and maintenance should be kept, including the

following:

a) the manufacturer's name;

b) the type and model of the equipment;

c) the purchase date;

d) the entry into service date;

e) the obsolescence date;

f) the serial and/or batch number;

g) information from the manufacturer, including users' instructions;

h) the safe working load, working load limit, maximum and minimum rated loads;

i) EC declaration of conformity;

j) active use, e.g. number of days;

k) current location and normal storage location;

l) exposure to any arduous conditions (e.g. chemicals, abrasion, heavy grit);

m) workmates retrieval;

n) details of examinations and inspections;

o) details of any repairs/renewals/alternations. (IRATA ICOP 2.9.1)

56

Lifespan

13. An item of PPE that reached the end of its lifespan specified by the manufacturer should be

withdrawn from service unless confirmed in writing by a competent person that it is

acceptable to use it. (IRATA ICOP 2.10.9)

57

Appendix 9: Business processes

Figure A9.1 Activity diagram for the add item of equipment business process

58

Figure A9.2 Activity diagram for the examine item of equipment business process

59

Appendix 10: Domain structural model and glossary

Figure A10.1 Domain structural model of PPE Management System – Increment 1

Figure A10.2 Domain structural model of PPE Management System – Increment 2

60

Table A10.1 Domain model glossary for the PPE Management System – Increment 1

Term Category Definition

address Attribute of Company The address of a Company

batchNumber Attribute of

EquipmentItem

The batch number of an EquipmentItem

Company Concept The company that owns an EquipmentItem

ConformityCertificate Concept The certificate of conformity of an EquipmentItem

dateOfCreation Attribute of

ConformityCertificate

The date of creation of a ConformityCertificate

dateOfEntryToService Attribute of

EquipmentItem

The date of entry to service of an EquipmentItem

dateOfManufacture Attribute of

EquipmentItem

The date of manufacture of EquipmentItem

dateOfObsolescence Attribute of

EquipmentItem

The date of obsolescence of an EquipmentItem

dateOfPurchase Attribute of

EquipmentItem

The date of purchase of a new EquipmentItem

EquipmentItem Concept An item of Personal Protective Equipment

EquipmentItem-

Company

Association A Company may own a number of EquipmentItems

EquipmentItem-


Association An EquipmentItem can have a ConformityCertificate

examinationInterval Attribute of

EquipmentItem

The examination interval of an EquipmentItem

inUse Attribute of

EquipmentItem

Indicates if an EquipmentItem is in use

loadRating Attribute of

EquipmentItem

The load rating of an EquipmentItem (can be either Safe

Working Load, Working Load Limit, or minimum breaking

load)

manufacturer Attribute of

EquipmentItem

The manufacturer of an EquipmentItem

61

model Attribute of

EquipmentItem

The model of an EquipmentItem

name Attribute of Company The name of a Company

serialNumber Attribute of

EquipmentItem

The serial number of an EquipmentItem

type Attribute of

EquipmentItem

The type of an EquipmentItem

Table A10.2 Domain model glossary for the PPE Management System – Increment 2


address Attribute of Company The address of a Company

address Attribute of Inspector The address of an Inspector

address Attribute of

Examination

The address of the premises at which an Examination was

carried out


EquipmentItem

The batch number of an EquipmentItem

category Attribute of

ExaminationReport

The category for an Examination (can be either: before first

use, 6 months interval, in accordance with examination

scheme, or following exceptional circumstances)





The date of creation of a ConformityCertificate


EquipmentItem

The date of entry to service of an EquipmentItem

dateOfExamination Attribute of

Examination

The date of an Examination

dateOfLastExamination Attribute of

ExaminationReport

The date of the last Examination of an EquipmentItem

dateOfManufacture Attribute of The date of manufacture of EquipmentItem

62

EquipmentItem

dateOfNextExamination Attribute of

ExaminationReport

The latest date by which the next Examination must be

carried out


EquipmentItem

The date of obsolescence of an EquipmentItem


EquipmentItem

The date of purchase of a new EquipmentItem

dateOfRepair Attribute of Repair The date of a Repair

dateOfReport Attribute of

ExaminationReport

The date of completion of an ExaminationReport

Defect Concept A defect of an EquipmentItem

description Attribute of Defect The description of a Defect

description Attribute of Repair The description of a Repair

employersName Attribute of Inspector The name of an Inspector's employer

employersAddress Attribute of Inspector The address of an Inspector's employer


EquipmentItem-

Company


EquipmentItem-



EquipmentItem-

ExaminationReport

Association An EquipmentItem may have a number of

ExaminationReports

EquipmentItem-

ExaminationReport

Association An EquipmentItem can have a current ExaminationReport

Examination Concept An examination session of an EquipmentItems by an

Inspector

Examination-Inspector Association An Examination is carried out by an Inspector


EquipmentItem

The examination interval of an EquipmentItem

ExaminationReport Concept A report from an Examination of an EquipmentItem

63

ExaminationReport-

Examination

Association An ExaminationReport is produced during or after an

Examination

ExaminationReport-

Defect

Association An ExaminationReport may contain a number of Defects

Inspector Concept A person competent to inspect EquipmentItem

inUse Attribute of

EquipmentItem

Indicates if an EquipmentItem is in use

isSafeToUse Attribute of

ExaminationReport

Indicates if the examined EquipmentItem is safe to use

isSelfEmployed Attribute of Inspector Indicates if an Inspector is self-employed


EquipmentItem

The load rating of an EquipmentItem


EquipmentItem

The manufacturer of an EquipmentItem

model Attribute of

EquipmentItem

The model of an EquipmentItem

name Attribute of Company The name of a Company

name Attribute of Inspector The name of an Inspector

part Attribute of Defect The part of an EquipmentItem affected by a Defect

purchasedNew Attribute of

EquipmentItem

Indicates if an EquipmentItem was purchased new or second

hand

qualification Attribute of Inspector The qualification of an Inspector

Repair Concept A repair of an EquipmentItem

Repair-Defect Association A Repair is to remedy a Defect

requiredRepair Attribute of Defect The repair required to remedy a Defect


EquipmentItem

The serial number of an EquipmentItem.

severity Attribute of Defect The severity of a Defect (Can be either: no risk, risk to

persons, serious risk to persons)

testsDescription Attribute of The description of tests carried out during an Examination

64

ExaminationReport

type Attribute of

EquipmentItem

The type of an EquipmentItem

65

Appendix 11: Use case models

Figure A11.1 Use case model of PPE Management System – Increment 1

66

Figure A11.2 Use case model of PPE Management System – increment 2

67

Table A11.1 A textual description of the add item of equipment use case

Identifier and name UC1 add item of equipment

Initiator Manager

Goal An item of equipment is added to the company's equipment pool.

Precondition None

Postcondition Details of an item of equipment will have been recorded and the item

will have been added to the company's pool of equipment in use.

Assumptions None

Extending cases UC1.1 add used item

Main success scenario

1. The manager obtains an item of equipment.

2. The manager chooses to add the item of equipment.

3. The manager enters the serial number, batch number, type, model, manufacturer, load

rating, date of manufacture, date of purchase and date of obsolescence of the item, and

the date of creation of the certificate of conformity.

4. The manager confirms that the item of equipment has not been used before.

5. The manager provides the creation date of the certificate of conformity.

6. The system records the provided details.

7. The system records that the item is now in use, the date of entry into service and schedules

the next examination.

8. The system confirms that the equipment is now in use and reveals the recorded details back

to the manager.

Extensions

4.a

4.a.1

extend::

5.a

5.a.1

5.a.2

the item of equipment used before

The manager confirms that the item of equipment has been used before

UC1.1 add used item

certificate of conformity not available or older than 12 months

The system reveals to the manager that the item requires an examination before it can be

used.

The manager sends the item for examination.

68

Table A11.2 A textual description of the create report use case

Identifier and name UC5 create report

Initiator Inspector

Goal Create examination report

Precondition Examination session is recorded

Postcondition One or more examination report will have been recorded.

Assumptions None

Main success scenario1. The inspector examines an item of equipment.2. The inspector finds the details of the item of equipment.

include:: UC2 view item of equipment3. The inspector chooses to create an examination report for the item of equipment.4. The inspector provides the category of the examination and the description of tests.5. The inspector indicates that the item is safe to use.6. The system records the provided details and the dateOfReport and dateOfLastExamination7. The system reveals the recorded details to the inspector.

Extensions

5.aextend::

one or more defects discoveredUC6 record defect

69

Appendix 12: Detailed software functional requirements

UC1 add item of equipmentSFR1: UC1, Step 2

Description: The system shall allow a manager to initiate adding an item of equipment.

Fit criterion: The Add item page should be displayed.

SFR2: UC1, Step 3

Description: The system shall obtain a serial number from the manger.

Fit criterion: A valid serial number shall be accepted.

SFR3: UC1, Step 3

Description: The system shall obtain a batch number from the manger.

Fit criterion: A valid batch number shall be accepted.

SFR4: UC1, Step 3

Description: The system shall obtain a type of equipment from the manger.

Fit criterion: A valid type of equipment shall be accepted.

SFR5: UC1, Step 3

Description: The system shall obtain a model of equipment from the manger.

Fit criterion: A valid model of equipment shall be accepted.

SFR6: UC1, Step 3

Description: The system shall obtain a manufacturer of equipment from the manger.

Fit criterion: A valid manufacturer of equipment shall be accepted.

SFR7: UC1, Step 3

Description: The system shall obtain a load rating from the manger.

Fit criterion: A valid load rating shall be accepted.

SFR8: UC1, Step 3

Description: The system shall obtain a date of manufacture from the manger.

Fit criterion: A valid date of manufacture shall be accepted.

SFR9: UC1, Step 3

Description: The system shall obtain a date of purchase from the manger.

Fit criterion: A valid date of purchase shall be accepted.

SFR10: UC1, Step 3

Description: The system shall obtain a date of obsolescence from the manger.

Fit criterion: A valid date of obsolescence shall be accepted.

70

SFR11: UC1, Step 3

Description: The system shall obtain an examination interval from the manger.

Fit criterion: A valid examination interval shall be accepted.

SFR12: UC1, Step 4

Description: The system shall accept confirmation that the item of equipment has not been

used before from the manager.

Fit criterion: A response indicating confirmation shall be accepted.

SFR13: UC1, Step 4.a.1

Description: The system shall accept confirmation that the item of equipment has been

used before from the manager.

Fit criterion: A response indicating confirmation shall be accepted.

SFR14: UC1, Step 5

Description: The system shall obtain a creation date of the certificate of conformity from the

manager.

Fit criterion: A valid creation date shall be accepted.

SFR15: UC1, Step 5.a.1

Description: Certificate of conformity not available or older than 12 months. The system

shall reveals to the manager that an item of equipment requires an examination before it

can be used.

Fit criterion: An examination request shall be revealed to the manager.

SFR16: UC1, Step 6

Description: The system shall record the provided details.

Fit criterion: The provided details shell be recorded.

SFR17: UC1, Step 7

Description: The system shall record that an item of equipment is now in use and the date

of entry into service. The system shall schedule the next examination.

Fit criterion: A fact that an item of equipment is in use and the date of entry into service

should be recorded. The next examination should be scheduled.

SFR 18: UC1, Step 8

Description: The system shall confirm that the equipment is now in use and reveal the

recorded details.

Fit criterion: A confirmation that the equipment is now in use and all the recorded details

should be displayed.

71

Appendix 13: Analysis models

Figure A13.1 Analysis structural model of PPE Management System – Increment 1

72

Figure A13.2 Analysis structural model of PPE Management System – Increment 2

73

Table A13.1 Analysis glossary for the PPE Management System – Increment 1


address Attribute of Company The address of a Company.


EquipmentItem

The batch number of an EquipmentItem.

Company Concept The company that owns an EquipmentItem.

ConformityCertificate Concept The certificate of conformity of an EquipmentItem.



The date of creation of a ConformityCertificate.

Must be later than dateOfManufacture.


EquipmentItem

The date of entry to service of an EquipmentItem.

Must be later than dateOfManufacture and

dateOfPurchase.


EquipmentItem

The date of manufacture of EquipmentItem.


EquipmentItem

The date of obsolescence of an EquipmentItem.

Must be later than dateOfManufacture, dateOfPurchase

and dateOfEntryToService.


EquipmentItem

The date of purchase of a new EquipmentItem.

Must be later than dateOfManufacture.

EquipmentItem Concept An item of Personal Protective Equipment.

EquipmentItem-

Company

Association A Company may own a number of EquipmentItems.

EquipmentItem-


Association An EquipmentItem can have a ConformityCertificate.

EquipmentItemControlle

r

Backing Bean A component of JSF, stores data about Equipment Item.


EquipmentItem

The examination interval of an EquipmentItem.

6 months unless an examination schedule is created.

inUse Attribute of

EquipmentItem

Indicates if an EquipmentItem is in use.


EquipmentItem

The load rating of an EquipmentItem.

Must expressed as one of 'Safe Working Load', 'Working

Load Limit', or 'minimum breaking load'.


EquipmentItem

The manufacturer of an EquipmentItem.

model Attribute of

EquipmentItem

The model of an EquipmentItem.

name Attribute of Company The name of a Company.


EquipmentItem

The serial number of an EquipmentItem.

type Attribute of

EquipmentItem

The type of an EquipmentItem.

Must be one of 'Rope', 'Harness', 'Connector', 'Descending

Device', 'Ascending Device', 'Back-up Device', 'Lanyard',

74

'Anchor Sling', 'Wire Strop', 'Work Seat', 'Helmet', 'Pulley',

'Other'.

Table A13.2 Analysis glossary for the PPE Management System – Increment 2


address Attribute of Company The address of a Company{not null}

address Attribute of Inspector The address of an Inspector{not null}


Examination


carried out{not null}


EquipmentItem

The batch number of an EquipmentItem{length = 50}


ExaminationReport

The category for an Examination{Must be one of: 'Before first use', '6 months interval', 'In

accordance with examination scheme', or 'Following

exceptional circumstances'}{not null}





The date of creation of a ConformityCertificate{Must be later than dateOfManufacture}{not null}


EquipmentItem

The date of entry to service of an EquipmentItem{Must be later than dateOfManufacture and

dateOfPurchase}{not null}


Examination

The date of an Examination{not null}


ExaminationReport

The date of the last Examination of an EquipmentItem{Must be before dateOfReport}{not null}


EquipmentItem



ExaminationReport


carried out{Derived from dateOfExamination in the linked

Examination object and examinationInterval in the linked

EquipmentItem object}{Must be later than dateOfExamination}{not null}

75


EquipmentItem

The date of obsolescence of an EquipmentItem{Must be later than dateOfManufacture, dateOfPurchase

and dateOfEntryToService}{not null}


EquipmentItem

The date of purchase of a new EquipmentItem{Must be later than dateOfManufacture}{not null}

dateOfRepair Attribute of Repair The date of a Repair{Must be later than dateOfExamination}{not null}


ExaminationReport

The date of completion of an ExaminationReport{Must be later or on the same day as dayOfExamination}{not null}


description Attribute of Defect The description of a Defect{not null}{length = 400}

description Attribute of Repair The description of a Repair{not null}{length = 400}

EmployedInspector Concept An employed inspector competent to examine

EquipmentItemSpecialises Inspector

employersName Attribute of

EmployedInspector

The name of an Inspector's employer{not null}{length = 50}

employersAddress Attribute of

EmployedInspector

The address of an Inspector's employer{not null}


EquipmentItem-

Company


EquipmentItem-



EquipmentItem-

ExaminationReport


ExaminationReports

EquipmentItem-

ExaminationReport


EquipmentItemControll

er

Backing bean A component of JSF, manages data related to Equipment

Item


Inspector



EquipmentItem

The examination interval of an EquipmentItem{6 months unless an examination schedule is created}{not null}


76

ExaminationReport-

Examination


Examination

ExaminationReport-

Defect


Inspector Concept A self-employed inspector competent to examine

EquipmentItemGeneralises EmployedInspector

inUse Attribute of

EquipmentItem

Indicates if an EquipmentItem is in use{not null}


ExaminationReport

Indicates if the examined EquipmentItem is safe to use{not null}


EquipmentItem

The load rating of an EquipmentItem{length = 400}


EquipmentItem

The manufacturer of an EquipmentItem{not null}{length = 50}

model Attribute of

EquipmentItem

The model of an EquipmentItem{not null}{length = 50}

name Attribute of Company The name of a Company{not null}{length = 50}

name Attribute of Inspector The name of an Inspector{not null}{length = 50}

part Attribute of Defect The part of an EquipmentItem affected by a Defect{length = 50}

qualification Attribute of Inspector The qualification of an Inspector{not null}{length = 50}



requiredRepair Attribute of Defect The repair required to remedy a Defect{length = 400}


EquipmentItem

The serial number of an EquipmentItem{length = 50}

severity Attribute of Defect The severity of a Defect{Must be one of: 'No risk', “Risk to persons', 'Serious risk

to persons'}{not null}

testsDescription Attribute of

ExaminationReport

The description of tests carried out during an

Examination{length = 400}

type Attribute of

EquipmentItem

The type of an EquipmentItem{Must be one of 'Rope', 'Harness', 'Connector',

'Descending Device', 'Ascending Device', 'Back-up Device',

'Lanyard', 'Anchor Sling', 'Wire Strop', 'Work Seat',

77

'Helmet', 'Pulley', 'Other'}{not null}

Listing A13.1 Constraints on EquipmentItem

context EquipmentItem inv:

self.dateOfPurchase > self.dateOfManufacture

self.dateOfEntryToService > self.dateOfManufacture and self.dateOfPurchase

self.dateOfObsolescence > self.dateOfManufacture and self.dateOfPurchase and self.dateOfEntryToService

self.inUse = True implies((currentDate – self.dateOfEntryToService < self.examinationInterval)

and (self.purchasedNew = True)and (currentDate – self.conformityCertificate.creationDate <

12 months))or((currentDate – self.currentReport.examination.dateOfExamination <

self.examinationInterval)and

(self.currentReport.isSafeToUse = True))or(self.currentReport.defect -> forAll(repair.notEmpty())))

self.pastReports->contains(self.currentReport) = False

Listing A13.2 Specification of the doAddItem() system operation

context EquipmentItemController::doAddItem() : String

pre:

- - self.equipmentItem.dateOfPurchase > self.EquipmentItem.dateOfManufacture

- - self.equipmentItem.dateOfEntryToService > self.EquipmentItem.dateOfManufacture and self.EquipementItem.dateOfPurchase

- - self.equipmentItem.dateOfObsolescence > self.EquipmentItem.dateOfManufacture and self.EquipmentItem.dateOfPurchase and self.EquipmentItem.dateOfEntryToService

- - self.conformityCertificate.creationDate.notEmpty() implies self.conformityCertificate.dateOfCreation > self.equipmentItem.dateOfManufacture

78

post:

- - a new EquipmentItem object, equipmentItem, will have been created (object creation), with serialNumber, batchNumber, type, model, manufacturer, loadRating, dateOfManufacture, dateOfPurchase and dateOfObsolescence set to values provided by the user

- - if dateOfCreation is provided, a new ConformityCertificate object, conformityCertificate, will have been created (object creation), with dateOfCreation set to the value provided by the user

- - equipmentItem will have been linked to company

- - if conformityCertificate was created, equipmentItem will have been linked to conformityCertificate

– - if conformityCertificate was created and dateOfCreation is less than 12 months old, equipmentItem.inUse will have been set to true

– - otherwise equipmentItem.inUse will have been set to false

- - equipmentItem.dateOfEntryToService will have been set to the current date

- - equipmentItem.examinationInterval will have been set to 6 months

- - equipmentItem, and if created, conformityCertificate will have been persisted to the database

- - a string containing the name of the confirmation page will have been returned

Listing A13.3 Specification of the doCreateReport() system operation

context ExaminationController::doCreateReport() : String

pre:

- - self.examination.inspector = currently logged on inspector

- - self.examination.notEmpty() = True

- - self.equipmentItem.notEmpty = True

post:

- - a new ExaminationReport object, examinationReport, will have been created, with category and testsDescription set to values provided bythe user, dateOfNextExamination set to the value equal to self.examination.dateOfExamination plus equipmentItem.examinationInterval, dateOfReport set to todays date

- - if the EquipmentItem object is linked to an ExaminationReport object via currentReport

- - dateOfLastExamination will have been set to the same value as the dateOfExamination of the Examination object linked to the ExaminationReport object linked to the EquipmentItem object in the role of currentReport

- - the ExaminationReport object linked to the EquipmentItem object in the role of currentReport will have been linked to EquipmentItem in the role of passedReports

79

- - otherwise dateOfLastExamination will have been set to null

- - if examinationReport is not linked to any Defect object or is linked only to Defect objects with severity of 'No risk' isSafeToUse will have been set to True

- - otherwise, isSafeToUse will have been set to False

- - examinationReport will have been linked to the EquipmentItem object in the role of currentReport

- - examinationReport will have been linked to the Examination object

- - examinationReport and any linked Defect objects will have been persisted to the database

- - a string containing the name of the confirmation page will have been returned

80

Appendix 14: Design models

Figure A14.1 Design structural model of PPE Management System – Increment 2

81

Table A14.1 Design glossary for the PPE Management System – Increment 2


address Attribute of Company The address of a Company{not null}

address Attribute of Inspector The address of an Inspector{not null}


Examination


carried out{not null}


EquipmentItem

The batch number of an EquipmentItem{length = 50}


ExaminationReport

The category for an Examination{Must be one of: 'Before first use', '6 months interval', 'In

accordance with examination scheme', or 'Following

exceptional circumstances'}{not null}





The date of creation of a ConformityCertificate{Must be later than dateOfManufacture}{not null}


EquipmentItem

The date of entry to service of an EquipmentItem{Must be later than dateOfManufacture and

dateOfPurchase}{not null}


Examination

The date of an Examination{not null}


ExaminationReport

The date of the last Examination of an EquipmentItem{Must be before dateOfReport}{not null}


EquipmentItem



ExaminationReport


carried out{Derived from dateOfExamination in the linked

Examination object and examinationInterval in the linked

EquipmentItem object}{Must be later than dateOfExamination}{not null}


EquipmentItem

The date of obsolescence of an EquipmentItem{Must be later than dateOfManufacture, dateOfPurchase

and dateOfEntryToService}{not null}


EquipmentItem

The date of purchase of a new EquipmentItem{Must be later than dateOfManufacture}

82

{not null}

dateOfRepair Attribute of Repair The date of a Repair{Must be later than dateOfExamination}{not null}


ExaminationReport

The date of completion of an ExaminationReport{Must be later or on the same day as dayOfExamination}{not null}


description Attribute of Defect The description of a Defect{not null}{length = 400}

description Attribute of Repair The description of a Repair{not null}{length = 400}

EmployedInspector Concept An employed inspector competent to examine

EquipmentItemSpecialises Inspector

employersName Attribute of

EmployedInspector

The name of an Inspector's employer{not null}{length = 50}

employersAddress Attribute of

EmployedInspector

The address of an Inspector's employer{not null}


EquipmentItem-

Company


EquipmentItem-



EquipmentItem-

ExaminationReport


ExaminationReports

EquipmentItem-

ExaminationReport


EquipmentItemControlle

r

Backing bean A component of JSF, manages data related to Equipment

Item{RequestScoped}{Named}

EquipmentItemEJB EJB A component of Java EE, manages data related to

EquipmentItem{Named}{Stateless}


Inspector


ExaminationController Backing bean A component of JSF, manages data related to Examination

and ExaminationReport{RequestScoped}{Named}

ExaminationEJB EJB A component of Java EE, manages data related to

83

EquipmentItem{Named}{Stateless}


EquipmentItem

The examination interval of an EquipmentItem{6 months unless an examination schedule is created}{not null}


ExaminationReport-

Examination


Examination

ExaminationReport-

Defect


id Attribute of all entities Primary key of entities stored in the database

Inspector Concept A self-employed inspector competent to examine

EquipmentItemGeneralises EmployedInspector

inUse Attribute of

EquipmentItem

Indicates if an EquipmentItem is in use{not null}


ExaminationReport

Indicates if the examined EquipmentItem is safe to use{not null}


EquipmentItem

The load rating of an EquipmentItem{length = 400}


EquipmentItem

The manufacturer of an EquipmentItem{not null}{length = 50}

model Attribute of

EquipmentItem

The model of an EquipmentItem{not null}{length = 50}

name Attribute of Company The name of a Company{not null}{length = 50}

name Attribute of Inspector The name of an Inspector{not null}{length = 50}

part Attribute of Defect The part of an EquipmentItem affected by a Defect{length = 50}

purchasedNew Attribute of

EquipmentItem

Indicates whether an item was purchased new{not null}

qualification Attribute of Inspector The qualification of an Inspector{not null}{length = 50}



requiredRepair Attribute of Defect The repair required to remedy a Defect{length = 400}


EquipmentItem

The serial number of an EquipmentItem{length = 50}

84

severity Attribute of Defect The severity of a Defect{Must be one of: 'No risk', “Risk to persons', 'Serious risk

to persons'}{not null}

testsDescription Attribute of

ExaminationReport

The description of tests carried out during an Examination{length = 400}

type Attribute of

EquipmentItem

The type of an EquipmentItem{Must be one of 'Rope', 'Harness', 'Connector',

'Descending Device', 'Ascending Device', 'Back-up Device',

'Lanyard', 'Anchor Sling', 'Wire Strop', 'Work Seat',

'Helmet', 'Pulley', 'Other'}{not null}

85

Appendix 15: persistence.xml file

Listing A15.1 Source code of the persistence.xml file

<?xml version="1.0" encoding="UTF-8"?><persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">  <persistence-unit name="PPEManagementSystemTestPU" transaction-

type="RESOURCE_LOCAL"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <class>uk.madewithbits.ppems.EquipmentItem</class> <class>uk.madewithbits.ppems.Company</class> <class>uk.madewithbits.ppems.ConformityCertificate</class> <properties> <property name="javax.persistence.schema-

generation.database.action" value="drop-and-create"/> <property name="javax.persistence.jdbc.driver" value=

"org.apache.derby.jdbc.EmbeddedDriver"/> <property name="javax.persistence.jdbc.url" value=

"jdbc:derby:memory:ppems;create=true"/> <property name="eclipselink.logging.level" value="INFO"/> </properties></persistence-unit> </persistence>

86

Appendix 16: Entities and their tests

Listing A16.1 Source code of the EquipmentItem entity

package uk.madewithbits.ppems.persistence;// import statements omitted

@Entity@NamedQueries({ @NamedQuery(name="findAllItems",

query="SELECT i FROM EquipmentItem i"), @NamedQuery(name="findWithSerialNo", query="SELECT i FROM EquipmentItem i WHERE i.serialNumber =

:serialnum"), @NamedQuery(name="findWithType", query="SELECT i FROM EquipmentItem i WHERE i.type = :type")})public class EquipmentItem implements Serializable { // ====================================== // = Attributes = // ====================================== private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @Column(length = 50) private String serialNumber; @Column(length = 50) private String batchNumber; @Enumerated(EnumType.STRING) @Column(nullable = false) private EquipmentType type; @Column(length = 50) private String model; @Column(length = 50) private String manufacturer; @Column(length = 400) private String loadRating; private LocalDate dateOfManufacture; private LocalDate dateOfPurchase; private LocalDate dateOfEntryToService; private LocalDate dateOfObsolescence; @Column(nullable = false) private Period examinationInterval; @Column(nullable = false) private boolean inUse; // ====================================== // = Associations = // ====================================== @ManyToOne @JoinColumn(nullable = false) private Company company; @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)

87

private ConformityCertificate cCertificate; // constructors, getters and setters omitted // ====================================== // = hashCode, equals, toString = // ====================================== // Generated by IDE

@Override public int hashCode() { int hash = 0; hash += (id != null ? id.hashCode() : 0); return hash; }

@Override public boolean equals(Object object) { if (!(object instanceof EquipmentItem)) { return false; } EquipmentItem other = (EquipmentItem) object; if ((this.id == null && other.id != null) || (this.id != null &&

!this.id.equals(other.id))) { return false; } return true; }

@Override public String toString() { StringBuilder sb = new StringBuilder(); sb.append("EquipmetItem"); sb.append("{id='").append(id).append('\''); sb.append(", serialNumber='").append(serialNumber).append('\''); sb.append(", batchNumber='").append(batchNumber).append('\''); sb.append(", type='").append(type).append('\''); sb.append(", model='").append(model).append('\''); sb.append(", manufacturer='").append(manufacturer).append('\''); sb.append(", loadRating='").append(loadRating).append('\''); sb.append(", dateOfManufacure='").append(dateOfManufacture).

append('\''); sb.append(", dateOfPurchase='").append(dateOfPurchase).

append('\''); sb.append(", dateOfEntryToService='").append(dateOfEntryToService).

append('\''); sb.append(", dateOfObsolescence='").append(dateOfObsolescence).

append('\''); sb.append(", examinationInterval='").append(examinationInterval).

append('\''); sb.append(", inUse='").append(inUse).append('\''); sb.append('}'); return sb.toString(); }}

88

Listing A16.2 Test class for the EquipmentItem entity

package test.uk.madewithbits.ppems.persistence;

// import statements omitted

/** * Tests of the EquipmentItem class. * @author akurczych */public class EquipmentItemTest { private static EntityManagerFactory emf = Persistence.

createEntityManagerFactory("PPEManagementSystemTestPU"); private EntityManager em; private EntityTransaction tx; private Set<EquipmentItem> dbContent; // Create an entity manager and set up the fixture @Before public void initEntityManager() throws Exception { em = emf.createEntityManager(); tx = em.getTransaction(); // Create an instance of Company Company company = new Company("AccessPro",

new Address("85 Bushy Hill Drive", null, "Guildford", "Surrey","GU1 2UG", "United Kingdom"));

// Create an instance of EquipmentItem EquipmentItem item1 = new EquipmentItem("0000000001", null,

EquipmentType.DESCENDINGDEVICE,"ID", "Petzl", "SWL 150 kg", LocalDate.of(2010, 1, 1), LocalDate.of(2010, 2, 1),

LocalDate.of(2010, 2, 2), null, Period.ofMonths(6), true); // Create an instance of ConformityCertificate ConformityCertificate cert1 = new ConformityCertificate(

LocalDate.of(2010, 1, 1)); // Set company and cCertificate of item item1.setCompany(company); item1.setcCertificate(cert1); // Create an instance of EquipmentItem EquipmentItem item2 = new EquipmentItem("0000000002", null,

EquipmentType.DESCENDINGDEVICE, "ID", "Petzl", "SWL 150kg", LocalDate.of(2010, 2, 2), LocalDate.of(2010, 3, 1),

LocalDate.of(2010, 3, 2), null, Period.ofMonths(6), true); // Create an instance of ConformityCertificate ConformityCertificate cert2 = new ConformityCertificate(

LocalDate.of(2010, 3, 1)); // Set company and cCertificate of item item2.setCompany(company); item2.setcCertificate(cert2); // Create an instance of EquipmentItem EquipmentItem item3 = new EquipmentItem("0000000003", null,

EquipmentType.ROPE, "Industrie", "Beal",

89

"Breaking load 3200 kg", LocalDate.of(2010, 3, 3), LocalDate.of(2010, 4, 4), LocalDate.of(2010, 4, 5), LocalDate.of(2020, 4, 5), Period.ofMonths(6), true);

// Create an instance of ConformityCertificate ConformityCertificate cert3 = new ConformityCertificate(

LocalDate.of(2010, 4, 4)); // Set company and cCertificate of item item3.setCompany(company); item3.setcCertificate(cert3); // Persist the company and the items to the database tx.begin(); em.persist(company); em.persist(item1); em.persist(item2); em.persist(item3); tx.commit(); // Set up database content list dbContent = new HashSet<>(); dbContent.add(item1); dbContent.add(item2); dbContent.add(item3); } // Remove the fixture and close entity manager @After public void closeEntityManager() throws Exception { tx.begin(); em.createQuery("DELETE FROM EquipmentItem e").executeUpdate(); em.createQuery("DELETE FROM Company c").executeUpdate(); em.createQuery(

"DELETE FROM ConformityCertificate c").executeUpdate(); tx.commit(); if (em != null) em.close(); } /** * Test 1 - persisting an entity to database. * Test for EquipmentItem with company and cCertificate set */ @Test public void test1PersistEquipmentItem() { // Record the number of items in the db int itemsNumBefore = em.createNamedQuery("findAllItems",

EquipmentItem.class).getResultList().size(); // Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem("08250SJ7115", null,

EquipmentType.HARNESS, "Navaho", "Petzl", "1 Person", LocalDate.of(2008, 9, 6), LocalDate.of(2009, 10, 30),

LocalDate.of(2009, 10, 30), LocalDate.of(2018, 9, 6), Period.ofMonths(6), true);

// Create an instance of ConformityCertificate ConformityCertificate cert = new ConformityCertificate(

LocalDate.of(2009, 10, 30));

90

// Retrieve an instance of Company Company company = em.createQuery(

"SELECT c FROM Company c", Company.class).getSingleResult(); // Set company and cCertificate of item item.setCompany(company); item.setcCertificate(cert); // Persist the item to the database tx.begin(); em.persist(item); tx.commit(); // Check that ids have been assigned assertNotNull("item's ID should not be null", item.getId()); assertNotNull("cert's ID should not be null", cert.getId()); // Check that the number of items in the db has increased by 1 int itemsNumAfter = em.createNamedQuery("findAllItems",

EquipmentItem.class).getResultList().size(); assertTrue("The number of items should increase by 1",

itemsNumAfter == (itemsNumBefore + 1)); } /** * Test 2 - persisting an entity to database. * Test for EquipmentItem with company not set. * Expected RollbackException */ @Test(expected = RollbackException.class) public void test2PersistEquipmentItem() {

// Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem("08250SJ7115", null,


LocalDate.of(2009, 10, 30), LocalDate.of(2018, 9, 6), Period.ofMonths(6), true);


LocalDate.of(2009, 10, 30)); // Set cCertificate of item item.setcCertificate(cert); // Persist the item to the database tx.begin(); em.persist(item); tx.commit(); } /** * Test 3 - persisting an entity to database. * Test for EquipmentItem with type not set. * Expected RollbackException */ @Test(expected = RollbackException.class) public void test3PersistEquipmentItem() {

91

// Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem("08250SJ7115", null, null, "Navaho", "Petzl", "1 Person", LocalDate.of(2008, 9, 6),

LocalDate.of(2009, 10, 30), LocalDate.of(2009, 10, 30), LocalDate.of(2018, 9, 6), Period.ofMonths(6), true);


LocalDate.of(2009, 10, 30)); // Retrieve an instance of Company Company company = em.createQuery(

"SELECT c FROM Company c", Company.class).getSingleResult(); // Set company and cCertificate of item item.setCompany(company); item.setcCertificate(cert); // Persist the item to the database tx.begin(); em.persist(item); tx.commit(); } /** * Test 4 - persisting an entity to database. * Test for EquipmentItem with examinationInterval not set. * Expected RollbackException */ @Test(expected = RollbackException.class) public void test4PersistEquipmentItem() { // Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem("08250SJ7115", null,


LocalDate.of(2009, 10, 30), LocalDate.of(2018, 9, 6), null, true);


LocalDate.of(2009, 10, 30)); // Retrieve an instance of Company Company company = em.createQuery(

"SELECT c FROM Company c", Company.class).getSingleResult(); // Set company and cCertificate of item item.setCompany(company); item.setcCertificate(cert); // Persist the item to the database tx.begin(); em.persist(item); tx.commit(); } /** * Test 5 - test of the query "findAllItems" of entity EquipmentItem. * Test for retrieving all EquipmentItem entities.

92

* @throws java.lang.Exception */ @Test public void test5findAllItems () throws Exception { // Retrieve all items in the database List allItems = em.createNamedQuery(

"findAllItems", EquipmentItem.class).getResultList(); // Check that Assert.assertEquals(

"findAllItems should retrieve all EquipmentItem entities", dbContent, new HashSet<EquipmentItem>(allItems)); } /** * Test 6 - test of the query "findWithSerialNo" of entity * EquipmentItem. * Test for retrieving an item in the database. * @throws java.lang.Exception */ @Test public void test6findWithSerialNo () throws Exception { Query query = em.createNamedQuery(

"findWithSerialNo", EquipmentItem.class); query.setParameter("serialnum", "0000000001"); EquipmentItem result = (EquipmentItem)query.getSingleResult(); Assert.assertEquals(

"EquipmentItem with the serial number 0000000001 should be returned", "0000000001", result.getSerialNumber()); } /** * Test 7 - test of the query "findWithSerialNo" of entity * EquipmentItem. * Test for retrieving an item not in the database. * @throws java.lang.Exception */ @Test public void test7findWithSerialNo () throws Exception { Query query = em.createNamedQuery(

"findWithSerialNo", EquipmentItem.class); query.setParameter("serialnum", "0000000011"); List<EquipmentItem> result = query.getResultList(); Assert.assertTrue("No items should be returned", result.isEmpty()); } /** * Test 8 - test of the query "findWithtype" of entity EquipmentItem. * Test for retrieving an items of a given type when more than 1 item * is in the db. * @throws java.lang.Exception */ @Test public void test8findWithType () throws Exception { Query query = em.createNamedQuery(

"findWithType", EquipmentItem.class); query.setParameter("type", EquipmentType.DESCENDINGDEVICE); List<EquipmentItem> result = query.getResultList(); Assert.assertTrue(

"2 items of type DESCENDINGDEVICE should be returned", result.size() == 2); }

93

/** * Test 9 - test of the query "findWithtype" of entity EquipmentItem. * Test for retrieving items of a given type when exactly 1 item is in * the db. * @throws java.lang.Exception */ @Test public void test9findWithType () throws Exception { Query query = em.createNamedQuery(

"findWithType", EquipmentItem.class); query.setParameter("type", EquipmentType.ROPE); List<EquipmentItem> result = query.getResultList(); Assert.assertTrue("1 items of type ROPE should be returned", result.size() == 1); } /** * Test 10 - test of the query "findWithtype" of entity EquipmentItem. * Test for retrieving items of a given type when there is no items of * that type in the db. * @throws java.lang.Exception */ @Test public void test10findWithType () throws Exception { Query query = em.createNamedQuery(

"findWithType", EquipmentItem.class); query.setParameter("type", EquipmentType.ASCENDINGDEVICE); List<EquipmentItem> result = query.getResultList(); Assert.assertTrue("No items should be returned", result.isEmpty()); }}

Listing A16.3 Source code of the ExamiantionReport entity

package uk.madewithbits.ppems.persistence;// import statements ommitted

/** * A class representing an examination report. * * @author akurczych */@Entitypublic class ExaminationReport implements Serializable {

// ====================================== // = Attributes = // ====================================== private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @NotNull @Enumerated(EnumType.STRING) private ExaminationCategory category;

94

private LocalDate dateOfLastExamination; @NotNull private LocalDate dateOfNextExamination; @NotNull private LocalDate dateOfReport; @Size(max = 400) @Column(length = 400) private String testsDescription; private boolean safeToUse;

// ====================================== // = Associations = // ====================================== @NotNull @ManyToOne @JoinColumn private EquipmentItem equipmentItem;

@NotNull @ManyToOne private Examination examination;

@NotNull @OneToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL) private List<Defect> defects = new LinkedList<>();

// ====================================== // = Constructors = // ====================================== public ExaminationReport() { }

public ExaminationReport(ExaminationCategory category, LocalDate dateOfReport, String testsDescription) {

this.category = category; this.dateOfReport = dateOfReport; this.testsDescription = testsDescription; } // Getters, setters, hashCode, equals and toString methods omitted}

Listing 16.4 Test class for the ExaminationReport entity

package test.uk.madewithbits.ppems.persistence;// import statements omitted

/** * Tests of the ExaminationReport entity * * @author akurczych */

95

public class ExaminationReportTest {

private static EntityManagerFactory emf = Persistence.createEntityManagerFactory(

"PPEManagementSystemTestPU"); private EntityManager em; private EntityTransaction tx; private ValidatorFactory vf; private Validator validator; private Address address; private EquipmentItem item; private EmployedInspector eInspector; private Examination examination ;

// Create an entity manager, validator and set up the fixture @Before public void init() throws Exception { em = emf.createEntityManager(); tx = em.getTransaction(); vf = Validation.buildDefaultValidatorFactory(); validator = vf.getValidator(); // Create an instace of an address address = new Address("85 Bushy Hill Drive", null, "Guildford", "Surrey", "GU1 2UG", "United Kingdom");

// Create an instance of Company Company company = new Company("AccessPro", address); // Create an instance of ConformityCertificate ConformityCertificate cert1 = new ConformityCertificate(

LocalDate.of(2017, 1, 1));

// Create an instance of EquipmentItem item = new EquipmentItem("0000000001", null,

EquipmentType.DESCENDINGDEVICE, "ID", "Petzl", "SWL 150 kg",

LocalDate.now().minusYears(1), LocalDate.now().minusMonths(6),

LocalDate.now().minusDays(1), null);

// Set examinationInterval and inUse item.setExaminationInterval(Period.ofMonths(6)); item.setInUse(false);

//Set dateOfEntryToService item.setDateOfEntryToService(LocalDate.of(2017, 1, 1));

// Set company and cCertificate of item item.setCompany(company); item.setConformityCertificate(cert1); // Create an instance of EmployedInspector eInspector = new EmployedInspector(

"John Smith", address, "Lyon PPE inspector", "AccessPro Abseiling", address); // Create an instance of Examination examination = new Examination(address, LocalDate.now());

96

// Set inspector in examination examination.setInspector(eInspector); // Persist company, item, eInspector and examination to the

// database tx.begin(); em.persist(company); em.persist(item); em.persist(eInspector); em.persist(examination); tx.commit(); }

// Close entity manager and validator factory @After public void close() throws Exception { if (em != null) { em.close(); } if (vf != null) { vf.close(); } }

/** * Test 1 Persist ExaminationReport - persisting an entity to database. * * Test for persisting and retrieving an instance of ExaminationReport * with no defects. */ @Test public void test1PersistExaminationReport() throws Exception {

// Create an instance of the tested class ExaminationReport eReport = new

ExaminationReport(ExaminationCategory.B_F_USE, LocalDate.now(), "No tests"); // Set safeToUse eReport.setSafeToUse(true); // Set dateOfNextReport eReport.setDateOfNextExamination(LocalDate.now().plusMonths(6));

// Set links between eReport and associated instances eReport.setExamination(examination); eReport.setEquipmentItem(item); item.setCurrentReport(eReport); // Persist the instance to the database tx.begin(); em.persist(eReport); tx.commit();

// Check that id has been assigned assertNotNull("ID should not be null", eReport.getId());

// Retrieve the instance from the db ExaminationReport eReport2 = em.find(ExaminationReport.class,

eReport.getId());

97

assertEquals("eReport should be retrieved from the db", eReport, eReport2);

// Check that examination was retrieved with eReport Examination examination2 = (Examination) eReport2.getExamination(); assertEquals("examination should be retrieved with eReport",

examination, examination2); // Check that item was retrieved with eReport EquipmentItem item2 = (EquipmentItem) eReport2.getEquipmentItem(); assertEquals("item should be retrieved with eReport", item, item2); } /** * Test 2 Persist ExaminationReport - persisting an entity to database. * * Test for persisting and retrieving an instance of ExaminationReport * with defects. */ @Test public void test2PersistExaminationReport() throws Exception {


ExaminationReport(ExaminationCategory.B_F_USE, LocalDate.now(), "No tests"); // Set date of the next examination eReport.setDateOfNextExamination(LocalDate.now().plusMonths(6)); // Create instances of Defect and add them to a List Defect defect1 = new Defect(DefectSeverity.SERIOUS_RISK_TO_PERSONS,

"Casing", "Crack visible externally", "Replace casing"); Defect defect2 = new Defect(DefectSeverity.SERIOUS_RISK_TO_PERSONS,

"Handle", "Broken handle", "Replace handle"); List<Defect> defects = new LinkedList<>(); defects.add(defect1); defects.add(defect2);

// Set links between eReport and associated instances eReport.setExamination(examination); eReport.setEquipmentItem(item); item.setCurrentReport(eReport); eReport.addDefects(defects); // Set safeToUse eReport.setSafeToUse(false); // Persist the instance to the database tx.begin(); em.persist(eReport); tx.commit();

// Check that id has been assigned assertNotNull("ID should not be null", eReport.getId());

// Retrieve the instance from the db ExaminationReport eReport2 = em.find(ExaminationReport.class,

eReport.getId());

98

assertEquals("eReport should be retrieved from the db", eReport, eReport2);

// Check that defect1 and defect2 were retrieved with eReport assertEquals("defect1 and defect2 should be retrieved with

eReport", eReport.getDefects(), eReport2.getDefects());

}

/** * Test 1 Validate ExaminationReport - validate an entity. * * Test for validating an instance of ExaminationReport with category * not set. */ @Test public void test1ValidateExamination() throws Exception {

// Create an instance of the tested class ExaminationReport eReport = new ExaminationReport(null, LocalDate.now(), "No tests"); // Set date of the next examination eReport.setDateOfNextExamination(LocalDate.now().plusMonths(6));

// Set links between eReport and associated instances eReport.setExamination(examination); eReport.setEquipmentItem(item); item.setCurrentReport(eReport);

// Validate the instace of the tested class Set<ConstraintViolation<ExaminationReport>> violations =

validator.validate(eReport); ConstraintViolation<ExaminationReport> violation1 =

violations.iterator().next();

// Check assertions assertEquals("1 ConstraintViolation expected", 1,

violations.size());

assertEquals("Property should be category", violation1.getPropertyPath().toString(), "category");

assertEquals("Message should be 'may not be null'",

violation1.getMessage(), "may not be null"); } /** * Test 2 Validate ExaminationReport - validate an entity. * * Test for validating an instance of ExaminationReport with excessive * length of testsDescription */ @Test public void test2ValidateExamination() throws Exception {

// Create an instance of the tested class

99

ExaminationReport eReport = new ExaminationReport(ExaminationCategory.B_F_USE, LocalDate.now(),

"Lorem ipsum dolor sit amet … Aenean"); // Set date of the next examination eReport.setDateOfNextExamination(LocalDate.now().plusMonths(6)); // Set links between eReport and associated instances eReport.setExamination(examination); eReport.setEquipmentItem(item); item.setCurrentReport(eReport);

// Validate the instace of the tested class Set<ConstraintViolation<ExaminationReport>> violations =



// Check assertions assertEquals("1 ConstraintViolation expected", 1,

violations.size());

assertEquals("Property should be 'testsDescription'", violation1.getPropertyPath().toString(), "testsDescription");

assertEquals("Message should be 'size must be between 0 and 400'", violation1.getMessage(), "size must be between 0 and 400");

}

/** * Test 3 Validate ExaminationReport - validate an entity. * * Test for validating an instance of ExaminationReport with * equipmentItem not set. */ @Test public void test3ValidateExamination() throws Exception {


ExaminationReport(ExaminationCategory.B_F_USE, LocalDate.now(), "No tests"); // Set date of the next examination eReport.setDateOfNextExamination(LocalDate.now().plusMonths(6));

// Set links between eReport and associated instances eReport.setExamination(examination); // eReport.setEquipmentItem(item); item.setCurrentReport(eReport); // Validate the instace of the tested class Set<ConstraintViolation<ExaminationReport>> violations =



// Check assertions

100

assertEquals("1 ConstraintViolation expected", 1, violations.size());

assertEquals("Property should be equipmentItem", violation1.getPropertyPath().toString(), "equipmentItem");

assertEquals("Message should be 'may not be null'", violation1.getMessage(), "may not be null");

}}

Listing A16.5 Source code of the Examination entity

package uk.madewithbits.ppems.persistence;// import statements omitted

/** * A class representing an equipment examination session. * * @author akurczych */@Entitypublic class Examination implements Serializable {

// ====================================== // = Attributes = // ====================================== private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @NotNull @Column(nullable = false) @Embedded private Address address; @NotNull @Column(nullable = false) private LocalDate dateOfExamination; // ====================================== // = Associations = // ====================================== @NotNull @OneToOne private Inspector inspector;

// ====================================== // = Constructors = // ====================================== public Examination() { }

public Examination(Address address, LocalDate dateOfExamination) { this.address = address; this.dateOfExamination = dateOfExamination;

101

} // ====================================== // = Getters & Setters = // ====================================== // Some getter and setter methods omitted /** * Get the value of inspector if it is an instance of EmployedInspector * * @return the value of inspector */ public EmployedInspector getEmployedInspector() { if (inspector instanceof EmployedInspector) { return (EmployedInspector)inspector; } else { return null; } } /** * Get the value of inspector * * @return the value of inspector */ public Inspector getInspector() { return inspector; } // hashCode, equals and toString omitted }

102

Appendix 17: Enterprise JavaBeans and their tests

Listing A17.1 Source code of EquipmentItemEJB

package uk.madewithbits.ppems.business;

// import statements ommited

/** * A class encapsulating business operation on EquipmentItem * * @author akurczych */@Named@Statelesspublic class EquipmentItemEJB {

// ====================================== // = Attributes = // ====================================== @PersistenceContext(unitName = "ppemsCMEPU") private EntityManager em;

// ====================================== // = Business Methods = // ====================================== public @NotNull EquipmentItem addItem( @NotNull EquipmentItem item, ConformityCertificate

conformityCertificate) { // Find and set the company Company company = em.createNamedQuery("findCompany",

Company.class).getSingleResult(); item.setCompany(company); // Set conformityCertificate if not null if (conformityCertificate != null) { item.setConformityCertificate(conformityCertificate); } // A new item with a certificate of conformity not older than 12 // months can be used without an examination. If no certificate is // available anexamination is required. if(item.getConformityCertificate() != null &&

this.isNoMoreThan12MonthsAgo( item.getConformityCertificate().getDateOfCreation())) {

item.setInUse(true); } else { item.setInUse(false); } // set the date of entry into service item.setDateOfEntryToService(LocalDate.now()); // Set the examination interval item.setExaminationInterval(Period.ofMonths(6)); // Persist the item

103

em.persist(item); return item; }

public void removeItem(@NotNull EquipmentItem item) { em.remove(em.merge(item)); }

public List<EquipmentItem> viewAllItems() { return em.createNamedQuery("findAllItems",

EquipmentItem.class).getResultList(); }

public EquipmentItem viewItemById(Long id) { return em.find(EquipmentItem.class, id); }

public List<EquipmentItem> viewItemBySerialNo(String serialNo) { TypedQuery<EquipmentItem> query =

em.createNamedQuery("findWithSerialNo", EquipmentItem.class); query.setParameter("serialno", serialNo); return query.getResultList(); }

public List<EquipmentItem> viewItemBySerialNoAndType(String serialNo, EquipmentType type) {

TypedQuery<EquipmentItem> query = em.createNamedQuery("findWithSerialNoAndType", EquipmentItem.class);

query.setParameter("serialno", serialNo); query.setParameter("type", type); return query.getResultList(); }

public List<EquipmentItem> viewItemByType(EquipmentType type) { TypedQuery<EquipmentItem> query = em.createNamedQuery("findWithType",

EquipmentItem.class); query.setParameter("type", type); return query.getResultList(); } // ====================================== // = Private Helper Methods = // ====================================== private boolean isNoMoreThan12MonthsAgo(LocalDate date) { return !(date.plusMonths(12).isBefore(LocalDate.now())); }}

Listing A17.2 Test class for EquipmentItemEJB

package test.uk.madewithbits.ppems.business;

// import statements omitted

104

/** * Tests of the EquipmentItemEJB. * * @author akurczych */public class EquipmentItemEJBTest {

EJBContainer ec; EquipmentItemEJB eItemEJB;

@Before public void initialiseContainer() throws Exception { ec = EJBContainer.createEJBContainer(); Context ctx = ec.getContext(); eItemEJB = (EquipmentItemEJB) ctx.lookup(

"java:global/classes/EquipmentItemEJBuk.madewithbits.ppems.business.EquipmentItemEJB");

}

@After public void closeContainer() { ec.close(); }

/** * Test 1 addItem - adding a new item of equipment. * Test for adding item and checking that all attributes are set. * Test for adding item with conformityCertificate older than one year */ @Test public void test1AddItem() { // Record the number of items in the db int itemsNumBefore = eItemEJB.viewAllItems().size(); // Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem(

"0000000004", null, EquipmentType.HARNESS,"Navaho", "Petzl","1 Person", LocalDate.of(2016, 1, 21), LocalDate.of(2016, 2, 21), LocalDate.of(2026, 1, 21));

// Create an instance of ConformityCertificate ConformityCertificate cert = new

ConformityCertificate(LocalDate.of(2016, 2, 21));

// Add the item eItemEJB.addItem(item, cert); // Check that the item is linked to the company assertTrue("The company of item should be set to AccessPro", item.getCompany().getName().equals("AccessPro")); // Check that the item is linked to the certificate assertNotNull("The item should be linked to the certificate", item.getConformityCertificate()); // Check that the item is not in use assertFalse("The item should not be in use", item.isInUse()); // Check that the date of entry into service is set assertEquals(

"The date of entry into service should be set to today's date", item.getDateOfEntryToService(), LocalDate.now());

105

// Check that the item's examination interval is set assertTrue(

"The item's examination interval should be set to 6 months", item.getExaminationInterval().getMonths() == 6);

// Check that ids have been assigned assertNotNull("item's ID should not be null", item.getId()); assertNotNull("cert's ID should not be null", cert.getId());

// Check that the number of items in the db has increased by 1 int itemsNumAfter = eItemEJB.viewAllItems().size(); assertTrue(

"The number of items should increase by 1",itemsNumAfter == (itemsNumBefore + 1));

} /** * Test 2 addItem - adding a new item of equipment. * Test for adding item with conformityCertificate with dateOfCreation * 12 months and 1 day ago */ @Test public void test2AddItem() {

// Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem("0000000004", null,



// Create an instance of ConformityCertificate with dateOfCreation // exactly 12 months ago

ConformityCertificate cert = new ConformityCertificate(LocalDate.now().minusDays(1).minusMonths(12));

// Add the item eItemEJB.addItem(item, cert); // Check that the item is linked to the certificate assertNotNull("The item should be linked to the certificate", item.getConformityCertificate()); // Check that the item is not in use assertFalse("The item should not be in use", item.isInUse()); } /** * Test 3 addItem - adding a new item of equipment. * Test for adding item with conformityCertificate exactly 12 months * old */ @Test public void test3AddItem() {




106


ConformityCertificate cert = new ConformityCertificate(LocalDate.now().minusMonths(12));

// Add the item eItemEJB.addItem(item, cert); // Check that the item is linked to the certificate assertNotNull("The item should be linked to the certificate", item.getConformityCertificate()); // Check that the item is in use assertTrue("The item should be in use", item.isInUse()); } /** * Test 4 addItem - adding a new item of equipment. * Test for adding item with conformityCertificate with dateOfCreation * less * than 12 months old by 1 day */ @Test public void test4AddItem() {





ConformityCertificate cert = new ConformityCertificate(LocalDate.now().plusDays(1).minusMonths(12));

// Add the item eItemEJB.addItem(item, cert); // Check that the item is linked to the certificate assertNotNull("The item should be linked to the certificate", item.getConformityCertificate()); // Check that the item is in use assertTrue("The item should be in use", item.isInUse()); } /** * Test 5 addItem - adding a new item of equipment. * Test for EquipmentItem with no cCertificate */ @Test public void test5AddItem() {




// Add the item

107

eItemEJB.addItem(item, null);

// Check that the item's certificate of conformity is not set assertNull("The item's conformityCertificate should be null ",

item.getConformityCertificate()); // Check that the item is not in use assertFalse("The item should not be in use", item.isInUse()); }

/** * Test 6 addItem - adding an item of equipment. * Test for EquipmentItem with type not set. Expected EJBException */ @Test(expected = EJBException.class) public void test2AddEquipmentItem() {

// Create an instance of EquipmentItem EquipmentItem item = new EquipmentItem("0000000004", null, null, "Navaho", "Petzl", "1 Person", LocalDate.of(2016, 1, 21),

LocalDate.of(2016, 2, 21), LocalDate.of(2026, 1, 21));



// Add the item of equipment eItemEJB.addItem(item, cert); }

/** * Test 1 removeItem - removing an item of equipment. Test for * EquipmentItem with cCertificate set */ @Test public void test1RemoveItem() {






// Add the item eItemEJB.addItem(item, cert);

// Record the number of items in the db int itemsNumBefore = eItemEJB.viewAllItems().size();

eItemEJB.removeItem(item);

// Check that the number of items in the db has decreased by 1 int itemsNumAfter = eItemEJB.viewAllItems().size();

108

assertTrue("The number of items should decrease by 1", itemsNumAfter == (itemsNumBefore - 1));

}

/*** Test 1 viewAllItems - test of viewing all items. Test for viewing* all EquipmentItems.

*/ @Test public void test1ViewAllItems() { // view all items in the database List allItems = eItemEJB.viewAllItems(); // Check that all EquipmentItems are retrieved. assertEquals(

"viewAllItems should retrieve all EquipmentItem entities", 3, allItems.size()); }

/** * Test 1 viewItemBySerialNo - test of viewing items of equipment by * serial number. * Test for retrieving an item in the database. */ @Test public void test1ViewItemBySerialNo() { List<EquipmentItem> results =

eItemEJB.viewItemBySerialNo("0000000001"); assertEquals(

"EquipmentItem with the serial number 0000000001 should be returned", "0000000001", results.iterator().next().getSerialNumber()); }

/** * Test 2 viewItemBySerialNo - test of viewing items of equipment by * serial number. * Test for viewing item not in the database. */ @Test public void test2ViewItemBySerialNo() { List<EquipmentItem> results =

eItemEJB.viewItemBySerialNo("0000000011"); assertTrue("No items should be returned", results.isEmpty()); }

/** * Test 1 viewItemByType - test of viewing items of equipment by type. * Test for viewing items of a given type when more than 1 item exists. */ @Test public void tes1ViewItemByType() { List<EquipmentItem> results =

eItemEJB.viewItemByType(EquipmentType.DESCENDINGDEVICE); assertTrue("2 items of type DESCENDINGDEVICE should be returned", results.size() == 2); }

/** * Test 2 viewItemByType - test of viewing items of equipment by type. * Test for viewing items of a given type when exactly 1 item is in the * db. */

109

@Test public void test2ViewItemByType() { List<EquipmentItem> results =

eItemEJB.viewItemByType(EquipmentType.ROPE); assertTrue("1 items of type ROPE should be returned", results.size() == 1); }

/** * Test 3 - test of viewing items of equipment by type. * Test for viewing items of a given type when there is no items of * that type in the db. */ @Test public void test3ViewItemByType() { List<EquipmentItem> results =

eItemEJB.viewItemByType(EquipmentType.ASCENDINGDEVICE); assertTrue("No items should be returned", results.isEmpty()); }

/** * Test 1 viewItemById - test of viewing items of equipment by id. * Test for viewing item with a given id that is in the db. */ @Test public void test1ViewItemById() { List<EquipmentItem> items =

eItemEJB.viewItemBySerialNo("0000000001"); EquipmentItem item = items.get(0); Long id = item.getId(); EquipmentItem result = eItemEJB.viewItemById(id); assertEquals("The same item should be returend", item, result); System.out.println(id); }

/** * Test 2 viewItemById - test of viewing items of equipment by id. * Test for viewing item with a given id that is not in the db. */ @Test public void test2ViewItemById() { EquipmentItem result = eItemEJB.viewItemById(new Long(111)); assertNull("Null should be returned", result); } /** * Test 1 viewItemBySerialNoAndType - test of viewing items of * equipment by serial number and type. * Test for retrieving items of a given type with a specific serial * number when there are two items of a given type in the db and the * serial number of one of them matches the searched serial number. */ @Test public void test1ViewItemBySerialNoAndType() { List<EquipmentItem> results = eItemEJB.viewItemBySerialNoAndType(

"0000000001",EquipmentType.DESCENDINGDEVICE); assertEquals("EquipmentItem with the serial number 0000000001” +

“should be returned", "0000000001", results.iterator().next().getSerialNumber());

assertTrue("1 item should be returned", results.size() == 1); }

110

}

Listing A17.3 Source code of ExamionationEJB

package uk.madewithbits.ppems.business;// import statements omitted/** * A class encapsulating business operation on Examination and * ExaminationReport * @author akurczych */@Statelesspublic class ExaminationEJB {

// ====================================== // = Attributes = // ====================================== @PersistenceContext(unitName = "ppemsCMEPU") private EntityManager em;

// ====================================== // = Business Methods = // ====================================== public void createReport(@NotNull ExaminationReport eReport, @NotNull

Examination examination, @NotNull EquipmentItem eItem, @NotNull List<Defect> defects) {

// Set examination as examination in eReport eReport.setExamination(examination);

// Add defects to defects in eReport eReport.addDefects(defects);

// Set eReport.safeToUse and eItem.inUse false if eReport is linked // to a Defect with severity other than NO_RISK, otherwise set it

// to true boolean safe = true; for (Defect defect : defects) { if (defect.getSeverity() != DefectSeverity.NO_RISK) { safe = false; } } eReport.setSafeToUse(safe); eItem.setInUse(safe);

// Set dateOfReport eReport.setDateOfReport(LocalDate.now());

// Set dateOfNextExamination eReport.setDateOfNextExamination(

examination.getDateOfExamination().plus(eItem.getExaminationInterval())); eItem.setDateOfNextExamination(eReport.getDateOfNextExamination());

// If eItem has currentReport set dateOfLastExamination in eReport // and add currentReport to pastReports in eItem if (eItem.getCurrentReport() != null) { eReport.setDateOfLastExamination(

eItem.getCurrentReport().getExamination().getDateOfExamination());

111

eItem.addPastReport(eItem.getCurrentReport()); }

// Set eReport.equipmentItem to eItem and eItem.currentReport to // eReport

eReport.setEquipmentItem(eItem); eItem.setCurrentReport(eReport);

// Persist eReport and update eItem em.persist(eReport); em.merge(eItem); }

/** * Set the value of inspector the currently logged in inspector and * persist examination to the database. * * @param examination new values of Examination */ public void recordExamination(@NotNull Examination examination) { // For now retrieve an instance of Inspector. // After implementing security the currently logged-in inspector

// will be retrieved. TypedQuery<Inspector> guery = em.createQuery(

"SELECT i FROM Inspector i", Inspector.class); Inspector inspector = guery.getSingleResult();

// Set inspector in examinationa and persist examination. examination.setInspector(inspector); em.persist(examination); }

public ExaminationReport viewReportById(Long id) { return em.find(ExaminationReport.class, id); }

}

Listing A17.4 Test class for ExaminationEJB

package test.uk.madewithbits.ppems.business;// import statements omitted/** * Tests of the Examination * * @author akurczych */public class ExaminationEJBTest { EJBContainer ec; EquipmentItemEJB eItemEJB; ExaminationEJB examinationEJB; private Address address; private EquipmentItem item; private Examination examination1; private Examination examination2; private Examination examination3; private ExaminationReport eReport1;

112

private ExaminationReport eReport2; private ExaminationReport eReport3; private List<Defect> defects;

@Before public void initialiseContainer() throws Exception { ec = EJBContainer.createEJBContainer(); Context ctx = ec.getContext(); eItemEJB = (EquipmentItemEJB) ctx.lookup( "java:global/classes/EquipmentItemEJB!

uk.madewithbits.ppems.business.EquipmentItemEJB"); examinationEJB = (ExaminationEJB) ctx.lookup( "java:global/classes/ExaminationEJB!

uk.madewithbits.ppems.business.ExaminationEJB"); // Create an instace of an address address = new Address("85 Bushy Hill Drive", null, "Guildford", "Surrey", "GU1 2UG", "United Kingdom"); // Create an instance of ConformityCertificate ConformityCertificate cert1 = new ConformityCertificate(

LocalDate.now().minusMonths(6));

// Create an instance of EquipmentItem item = new EquipmentItem("0000000001", null,

EquipmentType.DESCENDINGDEVICE, "ID", "Petzl", "SWL 150 kg", LocalDate.now().minusYears(1), LocalDate.now().minusMonths(6), LocalDate.now(), null);

// Create an instance of Examination examination1 = new Examination(address,

LocalDate.now().minusMonths(6)); // Create an instane of ExaminationReport eReport1 = new ExaminationReport(ExaminationCategory.B_F_USE, LocalDate.now().minusMonths(6), "No tests"); eReport1.setExamination(examination1); // Create an instance of Examination examination2 = new Examination(address,

LocalDate.now().minusMonths(3)); // Create an instane of ExaminationReport eReport2 = new ExaminationReport(

ExaminationCategory.E_CIRCUMSTANCES, LocalDate.now().minusMonths(3), "No tests"); eReport2.setExamination(examination2); // Create an instance of Examination examination3 = new Examination(address, LocalDate.now()); // Create an instane of ExaminationReport eReport3 = new ExaminationReport(

ExaminationCategory.SIX_M_INTERVAL, LocalDate.now(), "No tests"); // Create an empty list of defects defects = new LinkedList<>(); // Persist item and examinations eItemEJB.addItem(item, cert1); examinationEJB.recordExamination(examination1); examinationEJB.recordExamination(examination2);

113

examinationEJB.recordExamination(examination3); }

@After public void closeContainer() { ec.close(); } /** * Test 1 recordExamination - recording a new examination. * * Test for recording a new examination. */ @Test public void test1RecordExamination() {

// Create an instance of Examination Examination examination = new Examination(address,LocalDate.now()); // Record examination examinationEJB.recordExamination(examination); // Check that id has been assigned assertNotNull("ID should not be null", examination.getId()); // Check that the inspector was set assertNotNull("inspector in examination should be set",

examination.getInspector()); } /** * Test 1 createReport - creating a new report. * * Test for creating a new report for an item with no defects and no * current report. */ @Test public void test1CreateReport() { // Invoke createReport() examinationEJB.createReport(eReport3, examination3, item, defects); // Check that id has been assigned assertNotNull("ID should not be null", eReport3.getId()); // Check that examination has been set assertEquals("examination should be set",

eReport3.getExamination(), examination3); // Check that eReport3.safeToUse has been set to true assertTrue("eReport3.safeToUse should be true",

eReport3.isSafeToUse()); // Check that item.inUse has been set to true assertTrue("item.inUse should be set to true", item.isInUse()); // Check that eReport3.dateOfLastExamination is null assertNull("eReport3.dateOfLastExamination should be null",

eReport3.getDateOfLastExamination());

114

// Check that eReport3.dateOfNextExamionation is set to the

// dateOfExamination plus item.examinationInterval assertEquals("eReport3.dateOfNextExamionation should be

examionation.dateOfExamionation plus item.examinationInterval", eReport3.getDateOfNextExamination(), examination3.getDateOfExamination().plus(item.getExaminationInterval())); // Check that item.dateOfNextExamination is set to the

// dateOfExamination plus item.examinationInterval assertEquals("item.dateOfNextExamionation should be

examionation.dateOfExamionation plus item.examinationInterval", item.getDateOfNextExamination(), examination3.getDateOfExamination().plus(item.getExaminationInterval())); // Check that eReport3.equipmentItem is set to item assertEquals("eReport3.equipmentItem should be set to item",

eReport3.getEquipmentItem(), item); // Check that item.getCurrentReport is set to eReport3 assertEquals("item.getCurrentReport should be set to eReport3",

item.getCurrentReport(), eReport3); } /** * Test 2 createReport - creating a new report. * * Test for creating a new report for an item with no defects, a * current report and no past reports. */ @Test public void test2CreateReport() { // Set item.currentReport item.setCurrentReport(eReport1); eReport1.setEquipmentItem(item); eReport1.setDateOfNextExamination( eReport1.getExamination().getDateOfExamination().plus(

item.getExaminationInterval())); // Invoke createReport() examinationEJB.createReport(eReport3, examination3, item, defects); // Check that id has been assigned assertNotNull("ID should not be null", eReport3.getId()); // Check that examination has been set assertEquals("examination should be set",


eReport3.isSafeToUse()); // Check that item.inUse has been set to true assertTrue("item.inUse should be set to true", item.isInUse()); // Check that eReport3.getDateOfLastExamination() is equal to

115

// eReport1.examination.dateOfExamination assertEquals("eReport3.dateOfLastExamination should be equal to

eReport1.examination().dateOfExamination()", eReport3.getDateOfLastExamination(),

eReport1.getExamination().getDateOfExamination()); // Check that eReport3.dateOfNextExamionation is set to the


examionation.dateOfExamionation plus item.examinationInterval", eReport3.getDateOfNextExamination(), examination3.getDateOfExamination().plus(item.getExaminationInterval())); // Check that item.dateOfNextExamination is set to the


examionation.dateOfExamionation plus item.examinationInterval", item.getDateOfNextExamination(), examination3.getDateOfExamination().plus(item.getExaminationInterval())); // Check that eReport3.equipmentItem is set to item assertEquals("eReport3.equipmentItem should be set to item",


item.getCurrentReport(), eReport3); // Check that item.pastReports contains eReport1 assertTrue("item.pastReports should contain eReport1",

item.getPastReports().contains(eReport1)); } /** * Test 3 createReport - creating a new report. * * Test for creating a new report for an item with no defects, a * current report and a past report. */ @Test public void test3CreateReport() { // Add to item.pastReports and set item.currentReport item.addPastReport(eReport1); eReport1.setEquipmentItem(item); item.setCurrentReport(eReport2); eReport1.setDateOfNextExamination( eReport1.getExamination().getDateOfExamination().plus(

item.getExaminationInterval())); eReport2.setEquipmentItem(item); eReport2.setDateOfNextExamination( eReport2.getExamination().getDateOfExamination().plus(

item.getExaminationInterval())); // Invoke createReport() examinationEJB.createReport(eReport3, examination3, item, defects); // Check that id has been assigned assertNotNull("ID should not be null", eReport3.getId());

116

// Check that examination has been set assertEquals("examination should be set",


eReport3.isSafeToUse()); // Check that item.inUse has been set to true assertTrue("item.inUse should be set to true", item.isInUse()); // Check that eReport3.getDateOfLastExamination() is equal to // eReport2.examination.dateOfExamination assertEquals("eReport3.dateOfLastExamination should be equal to

eReport2.examination().dateOfExamination()", eReport3.getDateOfLastExamination(),

eReport2.getExamination().getDateOfExamination()); // Check that eReport3.dateOfNextExamionation is set to the


examionation.dateOfExamionation plus item.examinationInterval", eReport3.getDateOfNextExamination(),

examination3.getDateOfExamination().plus(item.getExaminationInterval()));

// Check that item.dateOfNextExamination is set to the


examionation.dateOfExamionation plus item.examinationInterval", item.getDateOfNextExamination(),


// Check that eReport3.equipmentItem is set to item assertEquals("eReport3.equipmentItem should be set to item",


item.getCurrentReport(), eReport3); // Check that item.pastReports constins eReport1 and eReport2 assertTrue("item.pastReports should contain eReport1 and eReport2", item.getPastReports().contains(eReport1) &&

item.getPastReports().contains(eReport2)); } /** * Test 4 createReport - creating a new report. * * Test for creating a new report for an item with NO_RISK defects only * and no current report. */ @Test public void test4CreateReport() { // Create instances of Defect and add them to a List

117

Defect defect1 = new Defect(DefectSeverity.NO_RISK, "Casing", "Scratches visible externally", null); Defect defect2 = new Defect(DefectSeverity.NO_RISK, "Handle", "Scratches on the handle", null); defects.add(defect1); defects.add(defect2); // Invoke createReport() examinationEJB.createReport(eReport3, examination3, item, defects); // Check that id has been assigned assertNotNull("ID should not be null", eReport3.getId()); // Check that examination has been set assertEquals("examination should be set",


eReport3.isSafeToUse()); // Check that item.inUse has been set to true assertTrue("item.inUse should be set to true", item.isInUse()); // Check that eReport3.getDateOfLastExamination() is null assertNull("eReport3.dateOfLastExamination should be null",

eReport3.getDateOfLastExamination()); // Check that eReport3.dateOfNextExamionation is set to the










item.getCurrentReport(), eReport3); } /** * Test 5 createReport - creating a new report. * Test for creating a new report for an item with defects other than * NO_RISK and no current report. */

118

@Test public void test5CreateReport() { // Create instances of Defect and add them to a List Defect defect1 = new Defect(

DefectSeverity.SERIOUS_RISK_TO_PERSONS, "Casing", "Crack visible externally", "Replace casing");

Defect defect2 = new Defect(DefectSeverity.SERIOUS_RISK_TO_PERSONS,"Handle", "Broken handle", "Replace handle");

defects.add(defect1); defects.add(defect2); // Invoke createReport() examinationEJB.createReport(eReport3, examination3, item, defects); // Check that id has been assigned assertNotNull("ID should not be null", eReport3.getId()); // Check that examination has been set assertEquals("examination should be set",

eReport3.getExamination(), examination3); // Check that eReport3.safeToUse has been set to false assertFalse("eReport3.safeToUse should be false",

eReport3.isSafeToUse()); // Check that item.inUse has been set to False assertFalse("item.inUse should be set to false", item.isInUse()); // Check that eReport3.getDateOfLastExamination() is null assertNull("eReport3.dateOfLastExamination should be null",

eReport3.getDateOfLastExamination()); // Check that eReport3.dateOfNextExamionation is set to the










item.getCurrentReport(), eReport3); }}

119

Appendix 18: Web pages navigation plan

Figure A18.1 Web pages navigation plan - Increment 1

120

Figure A18.2 Web pages navigation plan – Increment 2

121

Appendix 19: Web pages and backing beans

Listing A19.1 Source code of view-items.xhtml

<?xml version='1.0' encoding='UTF-8' ?><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:jsf="http://xmlns.jcp.org/jsf" xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:f="http://xmlns.jcp.org/jsf/core"> <head> <title>View items of PPE</title> </head> <body> <a href="add-item.xhtml">Add item of PPE</a> <h1>View items of PPE</h1> <form jsf:id="viewItemsForm"> <fieldset> <legend>Refine</legend> <div> <label for="serialNumber">Serial Number</label> <input type="text" jsf:id="serialNumber" jsf:value=

"#{equipmentItemController.equipmentItem.serialNumber}"/> </div> <div> <label for="type">Type</label> <select jsf:id="type" size="1"

jsf:value="#{equipmentItemController.equipmentItem.type}">

<f:selectItem itemValue="#{null}" itemLabel="select one" />

<f:selectItem itemValue="ANCHORSLING" itemLabel="Anchore Sling"/>

<f:selectItem itemValue="ASCENDINGDEVICE" itemLabel="Ascending Device"/>

<f:selectItem itemValue="BACKUPDEVICE" itemLabel="Backup Device"/>

<f:selectItem itemValue="CONNECTOR" itemLabel="Connector"/>

<f:selectItem itemValue="DESCENDINGDEVICE" itemLabel="Descending Device"/>

<f:selectItem itemValue="HARNESS" itemLabel="Harness"/> <f:selectItem itemValue="HELMET" itemLabel="Helmet"/> <f:selectItem itemValue="LANYARD" itemLabel="Lanyard"/> <f:selectItem itemValue="PULLEY" itemLabel="Pulley"/> <f:selectItem itemValue="ROPE" itemLabel="Rope"/> <f:selectItem itemValue="WIRESTROP" itemLabel=

"Wire Strop"/> <f:selectItem itemValue="WORKSEAT" itemLabel=

"Work Seat"/> <f:selectItem itemValue="OTHER" itemLabel="Other"/> </select> </div> <div> <input type="submit" value="View items" jsf:action=

"#{equipmentItemController.doReloadEquipmentItemsList()}">

122

<f:ajax execute="@form" render=":equipmentItemsList" /> </input> <input type="reset" value="Reset"/> <input type="button" value="View all items"

jsf:outcome="view-items.xhtml" /> </div> </fieldset> </form> <h:dataTable id="equipmentItemsList"

value="#{equipmentItemController.doViewItems()}" var="item"> <h:column> <f:facet name="header"> <h:outputText value="Serial Number"/> </f:facet> <h:outputText value="#{item.serialNumber}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Type"/> </f:facet> <h:outputText value="#{item.type}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Model"/> </f:facet> <h:outputText value="#{item.model}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Manufacturer"/> </f:facet> <h:outputText value="#{item.manufacturer}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Details"/> </f:facet> <h:button outcome="view-item-details.xhtml?id=#{item.id}"

value="Details"/> </h:column> </h:dataTable> </body></html>

Listing A19.2 Source code of EquipmentItemController backing bean

package uk.madewithbits.ppems.presentation;// import statements omitted

/** * A backing bean for controlling operations on EquipmentItem * * @author akurczych */@Named@RequestScopedpublic class EquipmentItemController {

123

// ====================================== // = Attributes = // ====================================== @Inject private EquipmentItemEJB equipmentItemEJB; private EquipmentItem equipmentItem = new EquipmentItem(); private ConformityCertificate conformityCertificate = new

ConformityCertificate();

// ====================================== // = Public Methods = // ====================================== public String doAddItem() { if (conformityCertificate.getDateOfCreation() != null) { equipmentItemEJB.addItem(equipmentItem, conformityCertificate); } else { equipmentItemEJB.addItem(equipmentItem, null); } return "add-item-confirmed.xhtml"; } public String doReloadEquipmentItemsList() { return "view-items.xhtml"; } public void doRemoveItem() { equipmentItemEJB.removeItem(equipmentItem); } public void doViewItemById() { equipmentItem =

equipmentItemEJB.viewItemById(equipmentItem.getId()); } public List<EquipmentItem> doViewItems() { String sn = equipmentItem.getSerialNumber(); EquipmentType t = equipmentItem.getType(); // If nighter serial number and typa are specified return all items if((sn == null || sn.equals("")) && t == null) { return equipmentItemEJB.viewAllItems(); } // If only type is specified return items of given type else if((sn == null || sn.equals("")) && t != null) { return equipmentItemEJB.viewItemByType(t); } // If only serial number is specified return items with the given

// serial number else if(!(sn == null || sn.equals("")) && t == null) { return equipmentItemEJB.viewItemBySerialNo(sn); } // If both serial number and type are specified return items of

// given // type with the serial number else { return equipmentItemEJB.viewItemBySerialNoAndType(sn, t); } }

// Getters and setters methods omitted}

124

Listing A19.3 Source code of ExaminationController backing bean

package uk.madewithbits.ppems.presentation;// import statements omitted

/** * A backing bean for controlling operations on Examination and * ExaminationReport * * @author akurczych */@Named(value = "examinationController")@SessionScopedpublic class ExaminationController implements Serializable {

// ====================================== // = Attributes = // ====================================== @Inject private ExaminationEJB examinationEJB;

@Inject private EquipmentItemEJB equipmentItemEJB;

private Examination examination; private ExaminationReport examinationReport; private EquipmentItem equipmentItem; private Defect defect; private List<Defect> defects;

// Initialise the attributes @PostConstruct public void init() { examination = new Examination(); examination.setAddress(new Address()); examinationReport = new ExaminationReport(); equipmentItem = new EquipmentItem(); defect = new Defect(); defects = new LinkedList<>(); }

// ====================================== // = Public Methods = // ====================================== public String doRecordExamination() { examinationEJB.recordExamination(examination); return "record-examination-confirmed.xhtml"; }

public String doCreateReport() { examinationEJB.createReport(examinationReport, examination, equipmentItem, defects); return "create-report-confirmed.xhtml"; }

public void doViewItemById() { equipmentItem =

equipmentItemEJB.viewItemById(equipmentItem.getId()); } public void doViewReportById() {

125

examinationReport = examinationEJB.viewReportById(examinationReport.getId());

}

// Getters and setters methods omitted

}

Listing A19.4 Source code of the create-report web page

<?xml version='1.0' encoding='UTF-8' ?><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:jsf="http://xmlns.jcp.org/jsf" xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:f="http://xmlns.jcp.org/jsf/core">



<f:metadata> <f:viewParam name="id"

value="#{examinationController.equipmentItem.id}" /> <f:viewAction action="#{examinationController.doViewItemById()}" /> </f:metadata>

<h:head> <title>Create Examination Report</title> </h:head> <body> <h1>Create Examination Report</h1> <div>

 Item: #{examinationController.equipmentItem.serialNumber} #{examinationController.equipmentItem.type.toString()} #{examinationController.equipmentItem.model} #{examinationController.equipmentItem.manufacturer} #{examinationController.equipmentItem.id} </div>

<form jsf:id="examinationReportForm"> <fieldset>

 <legend>Examination details</legend> <div>Enter examination details relevant to the selected

item</div> <div> <label for="examinationCategory">Examination

Category</label> <select jsf:id="examinationCategory" size="1"

required="required"jsf:value=

"#{examinationController.examinationReport.category}"> <f:selectItem itemValue="#{null}"

itemLabel="select one" />

126

http://xmlns.jcp.org/jsf/core

<f:selectItem itemValue="B_F_USE"itemLabel="Before First Use"/>

<f:selectItem itemValue="SIX_M_INTERVAL"itemLabel="6 Months Interval"/>

<f:selectItem itemValue="EXAMINATION_SCHEME" itemLabel="Examination Scheme"/>

<f:selectItem itemValue="E_CIRCUMSTANCES" itemLabel="Exceptional Circumstances"/>

</select> <h:message for="examinationCategory" /> </div>

<div> <label for="testsDescription">

Description of tests</label> <textarea jsf:id="testsDescription" jsf:value=

"#{examinationController.examinationReport.testsDescription}"> </textarea> <h:message for="testsDescription" /> </div> </fieldset> </form>



<form jsf:id="defectsForm"> <fieldset> <legend>Defects</legend> <div>Enter details of any defects</div> <div> <label for="severity">Defect Severity</label> <select jsf:id="severity" size="1"

jsf:value="#{examinationController.defect.severity}">

<f:selectItem itemValue="#{null}"itemLabel="select one" />

<f:selectItem itemValue="NO_RISK"itemLabel="No risk"/>

<f:selectItem itemValue="RISK_TO_PERSONS" itemLabel="Risk to persons"/>

<f:selectItem itemValue="SERIOUS_RISK_TO_PERSONS" itemLabel="Serious risk to persons"/>

</select> <h:message for="severity" /> </div> <div> <label for="part">Part</label> <input type="text" jsf:id="part" jsf:value="#{examinationController.defect.part}"/> <h:message for="part" /> </div> <div> <label for="description">Description of defect</label> <textarea jsf:id="description" jsf:value=

"#{examinationController.defect.description}"> </textarea> <h:message for="description" /> </div> <div> <label for="requiredRepair">Required repair</label>

127

<textarea jsf:id="requiredRepair" jsf:value=

"#{examinationController.defect.requiredRepair}"> </textarea> <h:message for="requiredRepair" /> </div> <div>

 <input type="submit" value="Add defect"

jsf:action="#{examinationController.addDefect(examinationController.defect)}">

<f:ajax execute="@form" render=

"severity part description requiredRepair defectsList" /> </input> <input type="reset" value="Reset"/> </div> </fieldset> </form>

 <h:dataTable id="defectsList"

value="#{examinationController.defects}" var="defect"> <h:column> <f:facet name="header"> <h:outputText value="Defect Severity"/> </f:facet> <h:outputText value="#{defect.severity.toString()}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Part"/> </f:facet> <h:outputText value="#{defect.part}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Description of defect"/> </f:facet> <h:outputText value="#{defect.description}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Required repair"/> </f:facet> <h:outputText value="#{defect.requiredRepair}"/> </h:column> </h:dataTable>

 <div> <input type="submit" value="Create Report"

form="examinationReportForm" jsf:action="#{examinationController.doCreateReport()}"/> <input type="reset" value="Reset"

form="examinationReportForm"/> <input type="button" value="Cancel"

jsf:outcome="dashboard.xhtml" /> </div>

128

</body></html>

Listing A19.5 Source code of the view-current-examination-report page

<?xml version='1.0' encoding='UTF-8' ?><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:jsf="http://xmlns.jcp.org/jsf" xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:f="http://xmlns.jcp.org/jsf/core"> <f:metadata> <f:viewParam name="id"

value="#{equipmentItemController.equipmentItem.id}" /> <f:viewAction

action="#{equipmentItemController.doViewItemById()}" /> </f:metadata> <head> <title>Current Examination Report</title> </head> <body> <h:panelGroup rendered=

"#{equipmentItemController.equipmentItem.currentReport == null}"> <div>The selected item does not have current examination

report.</div> </h:panelGroup>

<h:panelGroup rendered= "#{equipmentItemController.equipmentItem.currentReport != null}">

<h1>Current Examination Report</h1>

<h3>Examination carried out for</h3>

<div>#{equipmentItemController.equipmentItem.company.name}</div><div>#{equipmentItemController.equipmentItem.company.address.addressLine1}

</div><div>#{equipmentItemController.equipmentItem.company.address.addressLine2}

</div><div>#{equipmentItemController.equipmentItem.company.address.city}</div> <div>#{equipmentItemController.equipmentItem.company.address.county}</div> <div>#{equipmentItemController.equipmentItem.company.address.postcode}

</div> <div>#{equipmentItemController.equipmentItem.company.address.country}</div>

<h3>Address where the examination was carried out</h3> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

address.addressLine1}</div><div>#{equipmentItemController.equipmentItem.currentReport.examination.

address.addressLine2}</div><div>#{equipmentItemController.equipmentItem.currentReport.examination.

address.city}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

address.county}</div><div>#{equipmentItemController.equipmentItem.currentReport.examination.

129

address.postcode}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.address.country}</div>

<h3>Examined item of equipment</h3> <table> <tr> <td>Serial Number</td>

<td>#{equipmentItemController.equipmentItem.serialNumber}</td>

</tr> <tr> <td>Batch Number</td> <td>

#{equipmentItemController.equipmentItem.batchNumber}</td> </tr> <tr> <td>Type</td>

<td>#{equipmentItemController.equipmentItem.type.toString()}</td>

</tr> <tr> <td>Model</td> <td>#{equipmentItemController.equipmentItem.model}</td> </tr> <tr> <td>Manufacturer</td>

<td>#{equipmentItemController.equipmentItem.manufacturer}</td>

</tr> <tr> <td>Date Of Manufacture</td> <td>

<h:outputText value="#{equipmentItemController.equipmentItem.dateOfManufacture}"

converter="localDateConverter"/> </td> </tr> <tr> <td>Date Of First Use</td> <td>

<h:outputText value="#{equipmentItemController.equipmentItem.dateOfEntryToService}"

converter="localDateConverter"/></td> </tr> <tr> <td>Date Of Last Examination</td> <td>

<h:outputTextvalue="#{equipmentItemController.equipmentItem.

currentReport.dateOfLastExamination}" converter="localDateConverter"/></td> </tr> <tr> <td>Load Rating</td>

<td> #{equipmentItemController.equipmentItem.loadRating}</td>

</tr> </table>

<h3>Examination Details</h3>

130

<div>Examination Category</div> <div>#{equipmentItemController.equipmentItem.currentReport.category.

toString()}</div>

<div>Description Of Tests</div> <div>#{equipmentItemController.equipmentItem.currentReport.

testsDescription}</div>

<div>Defects</div> <h:dataTable id="defectsList"

value= "#{equipmentItemController.equipmentItem.currentReport.defects}"

var="defect"> <h:column> <f:facet name="header"> <h:outputText value="Defect Severity"/> </f:facet> <h:outputText value="#{defect.severity.toString()}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Part"/> </f:facet> <h:outputText value="#{defect.part}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Description of defect"/> </f:facet> <h:outputText value="#{defect.description}"/> </h:column> <h:column> <f:facet name="header"> <h:outputText value="Required repair"/> </f:facet> <h:outputText value="#{defect.requiredRepair}"/> </h:column> </h:dataTable>

<div>Is the item safe to use?</div> <div><h:outputText value=

"#{equipmentItemController.equipmentItem.currentReport.safeToUse ? 'Yes' : 'No'}" /></div>

<table> <tr> <td>Date Of Examination</td> <td><h:outputText

value="#{equipmentItemController.equipmentItem.currentReport.examination.dateOfExamination}"

converter="localDateConverter"/></td> </tr> <tr> <td>Date Of Next Examination</td> <td><h:outputText

value="#{equipmentItemController.equipmentItem.currentReport.dateOfNextExamination}"

converter="localDateConverter"/></td>

131

</tr> <tr> <td>Date Of Report</td> <td><h:outputText value=

"#{equipmentItemController.equipmentItem.currentReport.dateOfReport}"

converter="localDateConverter"/></td> </tr> </table>

<h3>Inspector</h3>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.name}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.address.addressLine1}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.address.addressLine2}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.address.city}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.address.county}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.address.postcode}</div>

<div>#{equipmentItemController.equipmentItem.currentReport.examination.inspector.address.country}</div>

<div>Qualifications</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

inspector.qualification}</div>

<div>Employer</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersName}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersAddress.addressLine1}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersAddress.addressLine2}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersAddress.city}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersAddress.postcode}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersAddress.county}</div> <div>#{equipmentItemController.equipmentItem.currentReport.examination.

employedInspector.employersAddress.country}</div>

</h:panelGroup>

<div> <input type="button" value="Back"

jsf:outcome="view-item-details.xhtml?id=#{equipmentItemController.equipmentItem.id}" /> <input type="button" value="Dashboard"

jsf:outcome="dashboard.xhtml" /> </div> </body></html>

132

Appendix 20: Screenshots of web pages

Figure A20.1 Screenshot of the add-item page with details of an item of equipment entered

133

Figure A20.2 Screenshot of the add-item-confirmed page

134

Figure A20.3 Screenshot of the page displaying all items of equipmentFigure A20.4 Screenshot of

the page displaying items of equipment of the Ascending Device type

Figure A20.5 Screenshot of a page displaying details of the item added earlier

135

Figure A20.6 Screenshot of removing the item added earlier

Figure A20.7 Screenshot of the remove-item-confirmed page

136

Figure A20.8 Screenshot of the page displaying items with overdue examination on 09-09-2017

Figure A20.9 Screenshot of recording examination with details entered

137

Figure A20.10 Screenshot of the record-examination-confirmed page

Figure A20.11 Screenshot of creating an examination report with details of one defect already

added

138

Figure A20.12 Screenshot of a page displaying an examination report (part 1)

139

Figure A20.13 Screenshot of a page displaying an examination report (part 2)

Figure A20.14 Screenshot of the page displaying items with overdue examination on 09-09-2017

with the item examined earlier no longer showing

140

Appendix 21: Requirements-based testing

A21.1 Increment 1

Testing session plan

1 Introduction

Date: 05.05.2017

Time: 11:00

Duration: 2 hours

Location: AccessPro Abseiling, 154 Bushy Hill Drive, Guildford, GU1 2UG

Participants: Rafal Kurczych – Manager at AccessPro Abseiling

The purpose of this session is to validate that the part of the product build so far meets customer

requirements.

The tests that will be performed check that the product meets the functional and non-functional

requirements specified. Since the user interface was not the main concern of the current stage of the

project, the tests are not concern with usability of the interface.

User input validation is not yet implemented and thus it will not be tested.

2 Use case model

Present the use case model of the entire system to the client.

Confirm that the use case model is complete (no use cases missing) and all use cases are

required.

Confirm the use cases covered in Increment 1.

◦ view item of equipment

◦ view item of equipment with serial number

◦ view item of equipment of given type

◦ add item of equipment

◦ remove item of equipment

Confirm the use cases that will be covered in Increment 2.

◦ record examination

◦ create report

141

◦ record defect

◦ view item of equipment with examination within next 4 weeks

◦ view item of equipment with overdue examination

◦ view current report

◦ view past report

3 Test cases

UC1 add item of equipment

1 Main success scenario

2 The certificate of conformity not available or older than 12 months

UC2 view item of equipment


UC2.1 view item of equipment with serial number


2 Item not found

UC2.2 view item of equipment of given type


UC3 remove item of equipment


Tests across UC1 add item of equipment - UC2 view item of equipment - UC3 remove item of

equipment

1 UC1 main success scenario – UC2 main success scenario – UC3 main success scenario

142

Summary of findings

Use case model

1. The system should inform the user about items of PPE that will require examination within

one month and allow to view them.

2. The system should inform the user about items of PPE that will reach the end of they lifespan

within one month and allow to view them.

3. The system should warn users about items of PPE with overdue examination and allow to

view them.

4. The system should warn users about items of PPE that reached the end of they lifespan and

allow to view them.

UC1 add item of equipment – main success scenario

5. Selection whether new or used item not yet implemented. Instead two sections of page are

visible – one for new items and one for used items. Possibly add radio buttons and reload the

next part of the page depending what info should be entered.

UC2 view item of equipment – main success scenario

6. The type of equipment is displayed in capital letters as with multiple words joined. Separate

words and transform to lower case.

7. Possibly in the future improve refining of items to be displayed by adding properties: model,

manufacturer, etc.

A21.2 Increment 2

Testing session plan

1 Introduction

Date: 18.08.2017

Time: 10:00

Duration: 2 hours

Location: AccessPro Abseiling, 154 Bushy Hill Drive, Guildford, GU1 2UG

Participants: Rafal Kurczych – Manager at AccessPro Abseiling

The purpose of this session is to validate that the part of the product build so far meets customer

requirements.

143

The tests that will be performed check that the product meets the functional and non-functional

requirements specified. Since the user interface was not the main concern of the current stage of the

project, the tests are not concern with usability of the interface.

User input validation is not fully implemented and thus it will not be tested.

2 Use case model

Present the use case model of the entire system to the client.

Confirm that the use case model is complete (no use cases missing) and all use cases are

required.

Confirm the use cases covered in iteration 2.

◦ record examination

◦ create report

◦ record defect

◦ view item of equipment with examination within one month

◦ view item of equipment with overdue examination

◦ view current report

◦ view past report

3 Test cases

UC2.1 view items of equipment with examination within one month

1 Main success scenario (MSS)

UC2.2 view items of equipment with overdue examination

1 MSS

UC4 record examination

1 MSS

UC5 create report

1 MSS – item with no previous reports

2 MSS – item with one previous report

3 MSS – item with two previous reports

UC6 record defect

1 MSS – defects but items assessed as safe and remains in-use.

2 Defects which result in item assessed as unsafe and out-of-use

UC7 view current report

144


UC8 view past report


2 No past reports

Test across use cases: UC1(MSS) - UC4(MSS) – UC5(MSS – item with no previous reports) –

UC6(defects but item safe) – UC7(MSS) – UC8(no past reports)

Test across use cases: UC4(MSS) – UC5(MSS- item with one previous report) – UC6(defects – item

unsafe) – UC7(MSS) – UC8(MSS – one past report)

Summary of findings

Use case model

1. Possible extension of the system could allow to record an inventory of equipment.

2. Supervisor and managers should be able to record equipment defects and thus change status

of equipment to 'not in use', without recording examination/creating report.

UC2.1 view items of equipment with examination within one month – main success scenario

3. The system does not allow refining the list of items of equipment with examination within

one month (e.g. show items of given type with examination within one month).

4. Once the user moves from view items of equipment with examination within one month to

view details of an item it is not possible to go back to view items of equipment with

examination within one month.

UC2.1 view items of equipment with overdue examination – main success scenario

5. The system does not allow refining the list of items of equipment with overdue examination

(e.g. show items of given type with overdue examination).

6. Once the user moves from view items of equipment with overdue examination to view

details of an item it is not possible to go back to view items of equipment with overdue

examination.

7. The system displays items with overdue examination but does not change their status to not

in use. This will be dealt with when implementing notifications.

UC5 create report – main success scenario – no defects,

8. When selecting an item of equipment to create examination report, it is not possible to

refine the list to only show items with overdue examination or with examination within one

month.

145

Appendix 22: Stakeholders impact analysis

Table A22.1 Stakeholders impact analysis

Stakeholder Legitimate interests Project's / product's impact

Developer - project completed successfully

and on time- working system produced with

minimal amount of bugs

Client

(company

owners)

- system working correctly obtained- system improves PPE maintenance

procedures- system ensures that PPE

information is maintained and

inspections carried out in

accordance with relevant

legislations- project cause minimal disruption

to the company

- the product should have a positive impact as it

should improve PPE maintenance- the product should have a positive impact as it

should help to ensure that PPE information

keeping and inspections are in accordance with

legislations

PPE

inspectors

- personal data protected- system easy to use and does not

lead to significant increase in

workload- system ensures that PPE



legislations

- the product has potential to have a negative

impact as personal data will be stored- the product has potential to have a negative

impact for uses with no/low computer abilities- the product should have a positive impact as it

should improve the way inspection results are

recorded- the product should have a positive impact as it

should help to ensure that PPE inspections

carried out in accordance with relevant

legislations

AccessPro

managers







legislations


impact as personal data will be stored- the product may have negative impact as

more PPE information may require recording

resulting in increase in workload- the product has potential to have a negative


should improve the way PPE informations are


146

Stakeholder Legitimate interests Project's / product's impact



legislations

AccessPro

supervisors







legislations- PPE is safe to use


impact as personal data will be stored- the product may have negative impact as

more PPE information may require recording

resulting in increase in workload- the product has potential to have a negative


should improve the way PPE informations are




legislations- the product should have a positive impact as it

should help to ensure that PPE is safe to use

AccessPro

technicians



workload- PPE is safe to use


impact as personal data will be stored- the product should have a positive impact as it

should help to ensure that PPE is safe to use- the product has potential to have a negative

impact for uses with no/low computer abilities

AccessPro

user-tester

- personal data protected- user tests cause minimal

disruption to their work schedule

147

Appendix 23: Sample project journal entry

Session 24Date: 17.03.17 Time: 3 hours Week: 6 Task: 9.3.1 TMA 02

Work

Created tests and implemented the last two entities: Company and ConformityCertificate. Checked

the resulted database schema.

Comments

I decided to use the database schema only for enforcing of basic constrains. This is because the

drawbacks of using database for validation (Goncalves, p. 69). I will implement data validation using

Bean Validation in the application layer and using JavaScript on the client later in the later stages of

the project.

Problems

A review of the generated db schema showed that composed classes, dates and period are stored as

BLOBs. The problem with the composed objects (Address in Company) was solved using JPA's

@Embeddable annotation. Result – two classes mapped to one table. Unfortunately the current

version of JPA does not support java.time classes. For now I will leave them as BLOBs and check if it is

stored and retrieved correctly. Converters will have to be written as some point to ensure

appropriate database storage format.

Next work planned

Implement associations

148

Appendix 24: Communication with the tutor

A sample progress report sent to the tutor on the 12.06.2017.

This is an update on the work completed over the last two weeks.

Week 13 01-07.05.2017

I finished creating JSF pages. I solved some problems I had with rendering the pages, which

was caused by incorrect entries in the web.xml configuration file. I also implemented

converters between String and LocalDate. Although the part of the system covered in the

first iteration (adding, viewing and removing items of PPE) is now completed there are still

some aspects that need to be implemented or improved, such as data validation or passing

of data between different pages. However rather than polishing this part of the system I

decided to start implementing other parts, leaving some detailed implementation to later

stages when more of the system is completed.

Evaluation of the completed part of the system was carried out by a manager from AccessPro

Abseiling.

Finally, I reviewed the project plan, reducing the number of iterations from 3 to 2, and wrote

down some advantages and disadvantages of Java EE platform that I discovered so far.

Week 14 08-14.05.2017

Starting with domain modelling again, I identified new business process that is the focus of

this iteration and updated the domain structural model and the glossary, adding few new

classes.

I then moved on to requirements. During the first iteration I found that use case model and

elaborated use case descriptions were much more useful in the development process than

the long list of detailed software requirements. I thus decided to only use use cases in this

iteration.

This week I will work on the analysis model of the system.

Kind Regards,

Andrzej Kurczych

149

Table A24.1 Record of communication with the tutor

Date Sender Subject Content

29.01.17 C. Damm Welcome message from your

TM470 tutor Ref: 155392460

An introduction from my tutor.

02.02.17 A. Kurczych Re: Welcome message from

your TM470 tutor Ref:

155392460

An introduction from me and two project

proposals.

02.02.17 C. Damm Re: Welcome message from


155392460

A reply from the tutor with comments on and

approval of both proposals.

03.02.17 A. Kurczych Re: Welcome message from


155392460

A confirmation of which project proposal I

chose to proceed with, some additional

explanations of my project, and an outline of

work planned for the next two weeks.

03.02.17 C. Damm Re: Welcome message from


155392460

A reply from my tutor approving my decisions.

05.02.17 C. Damm TM470 - Tutorial One on

Wednesday 8th February at

7.30 pm Ref: 155604079

Information about an on-line tutorial.

19.02.17 A. Kurczych TM470 Progress update

19.02.2017

A progress update on the work completed

and planned. Few question about project

tasks, schedule and risk register.

19.02.17 C. Damm Re: TM470 Progress update

19.02.2017

A reply from my tutor answering my

questions.

27.02.17 C. Damm Reminder: Library / research

skills session - 14 March Ref:

156558765

A reminder about upcoming library and

research skill session.

05.03.17 A. Kurczych TM470 progress update

05.03.2017


and planned.

05.03.17 C. Damm Re: TM470 progress update

05.03.2017

A reply from my tutor.

19.03.17 A. Kurczych TM470 progress update

19.03.2017

An updated on the progress and problems

encountered.


19.03.2017

A reply from my tutor containing some

advice.

22.03.17 A. Kurczych TM470 - TMA02 question A question about the content of TMA02.

22.03.17 C. Damm Re: TM470 - TMA02 question A reply from my tutor explaining the content

of TMA02.

28.03.17 C. Damm TM470 - Tutorial Two on

Monday 3rd April at 7.30 pm

A reminder about upcoming online tutorial.

150

Ref: 157803768

06.04.17 A. Kurczych TM470 progress update and

questions 06.04.2017

A progress update with questions about word

count and possibility of extension for

submitting of TMA02.


and questions 06.04.2017

A reply form my tutor with answers and

granting the extension.

30.04.17 A. Kurczych TM470 progress update A progress update covering 3 weeks.

02.05.17 C. Damm Re: TM470 progress update An acknowledgement of the progress update

with some advice.

15.05.17 A. Kurczych TM470 progress update -

15.05.2017


and planned.

19.05.17 C. Damm Re: TM470 progress update -

15.05.2017

An acknowledgement of the progress update.


30.05.2017


and planned.


30.05.2017



12.06.2017


and planned.


12.06.2017

An acknowledgement of the progress update

with some advice.

20.06.17 C. Damm TM470 Tutorial 3 - Thursday

29th June at 19.00 Ref:

161419051

Information about upcoming tutorial with

some advice regarding TMA03.


02.07.2017


and planned.

03.07.17 C. Damm RE: TM470 progress update -

02.07.2017


17.07.17 A. Kurczych TM470 progress update and

question to TMA03 -

17.07.2017

A progress update with questions about

comments to TMA03.

20.07.17 C.Damm Re: TM470 progress update

and question to TMA03 -

17.07.2017

An acknowledgement of the progress update

with answers to the questions.

20.07.17 A. Kurczych Re: TM470 progress update

and question to TMA03 -

17.07.2017

Additional explanations to tutors comments.


31.07.2017


and planned.

31.07.17 C. Damm Re: M470 progress update -

31.07.2017


151


13.08.2017


and planned.


13.08.2017


18.08.17 C. Damm Tutorial - Tuesday 28th

August at 19.30 Ref:

164927656

Information about upcoming tutorial with

some advice regarding EMA.


27.08.2017


and planned.


27.08.2017


152

development of a personal protective equipment management system for a rope access company

Documents