Worcester polytechnic institute

Figure 6 – Class diagram

Inside of the DoorCell.java file, there is also another class defined –

MouseButtonListener, that is responsible for reacting to various events, more specifically 

events occurring because of the user input.  As the name of the class implies, the exact 

nature of events is manipulation by the mouse.

The class-specific variables shown in the figure above are given the exact role 

that their name implies.  The name variable is responsible for holding the name of the 

---

17

door, which can be customized through the XML file, controlling it, same with the 

password variable.  Because this is the initial phase of this long-term project, the 

passwords are not encrypted, however it is possible to create a function that will look for 

that specific string in the XML file and encrypt and mark that it is encrypted every time it 

is changed while the world is being initialized.  That would, of course, also require that 

the client be able to decrypt the password in order to check if what the user has entered is 

actually the same as the set password.  However, this is part of the plan for future work.  

The Boolean value passFrameOpen plays a more mechanical role and prevents multiple 

copies of Java frames being open, due to the fact that for an unknown reason the mouse 

events are registered several times and would consequently show several dialogs to 

appear for the user to input the password, which is a highly undesirable behavior.

A sample walkthrough of how the doors are used can be seen below:

1. The user enters the world.

2. The user might interact with people or objects in the lobby first

3. The user walks up to the door

4. The user uses the left mouse button to click on the door

5. If there are no previous door dialogs open for this user, a password dialog appears

6. The user enters the password

7. If the password is correct, the user is transported inside of the room, guarded by 

the door.  If the password is incorrect, the user can enter the password again, 

unlimited number of tries as of the time of this writing.

This can be better demonstrated by a diagram:

---

What happens behind the scenes after the user enters the password is relatively 

straight-forward – there has to be a mechanism to check the entered password against the 

actual password stored in the door settings.  However, there is a small difficulty for when 

the password is correct.  Because the doors are meant to keep people out, there has to be a 

mechanism that checks if this is the case, so as not to ask the users for a passwor

order to be able to leave a room.  Such behavior would not make much sense in the first 

place and would probably not please the users of the system.

solved by checking the user’s current coordinates in relation to the door’s

thus figuring out if the user is inside or outside of the room.  This works fine for doors 

that are positioned in the north

side, however a new variable has to be added to the door X

where the outside of the door is facing, so that the right set of coordinates are checked to 

determine where the user is located.

• Enter world

• Interract 

with objects

1

• Activate 

door