2. create a new member. A member has a name, and an optional email address.
   2. If the member has an email address it must be unique (two different members cannot have the same email address).
   4. When a member is created the member is assigned a new unique random 6 character alpha numeric member id. This id must be unique and no other member in the registry should be able to get the same id.
5. You should be able to list all members.
7. You should be able to select a particular member see the detailed information about the member. You should then be able to:
   2. delete the member
   4. add a new boat. A boat has a name, type (sailboat, motorboat, motorsailer, or canoe). Depending on the type there could be different information needed:
      2. Sailboat: length in meter, depth in meter.
      4. Motorboat: length in meter, engine power in horse powers.
      6. Motorsailer: length in meter, depth in meter, engine power in horse powers.
      8. Canoe: length in meter.
   7. Select a boat and see the detailed information about the boat. You should then be able to:
      1. delete the boat
10. You should be able to quit the application
12. The registry information should be loaded from a file registry.data when the application starts. See the example.

MEMBER:Margaret H..t@nasa.gov:lkd432

BOAT:apollo1:sailboat:20:4

BOAT:appollo3:motorboat:20:50

MEMBER:Allan T..n@bletchleypark.org.uk:kh654s

BOAT:enigma:canoe:4

MEMBER:Barbara L..a@mit.edu:bg54w2

BOAT:substitution:motorsailer:17:4:30

MEMBER:Charles Babbage::8ww3ls

6. The registry information should be saved to a file registry.data when the application exits. example

MEMBER:Margaret H..t@nasa.gov:lkd432

BOAT:apollo1:sailboat:20:4

BOAT:appollo3:motorboat:20:50

MEMBER:Allan T..n@bletchleypark.org.uk:kh654s

BOAT:enigma:canoe:4

MEMBER:Barbara L..a@mit.edu:bg54w2

BOAT:substitution:motorsailer:17:4:30

MEMBER:Charles Babbage::8ww3ls

7. There should be at least one class diagram showing the application structure with all classes and correct relations between the classes. You do not need to add every operation in the class diagram.

8. Basic error handling, i.e. it should not crash. No need for user friendly error messages.

File Loading/Saving Format

The requirement is that the data of the application should be loaded from a file when the application starts, and saved to a file when the application ends. The idea is to load the whole file, convert it to nice to work with objects. When the user quits, the whole file is overwritten with new data. Trying to load/save continously or manipulate the file incrementally will only make things more complicated.

The format of the file is as follows:

MEMBER:Member Name:optional email adress:member id optional BOAT:boat name:sailboat|motorboat|motorsailer|canoe:boat length:optional boat depth|engine power: optional engine power

Extended Requirements

2. You should be able to select a particular member and edit the member
   2. name
   4. email adress
5. Select a members boat and edit its:
   2. name
   4. type
   6. type information (length etc.)
8. Use the strategy design pattern to design and implement an extendible and flexible way of searching for members. For example searching for members with sailboats, or searching for members with a particular member id, etc.
10. Extend the basic way of searching with the composite design pattern to enable boolean expression type searching. E.g. members with sailboats and boats with a length over 10m or a motorboat (type=sailboat and length>10) or type=motorboat. For this requirements it is sufficient that you design and implement, there is no need for adding a user interface for this.
12. Unit testing - add a few automatic unit tests to the codebase. It should be something more than just simple getters and setters.
14. The application should handle input-errors well with user friendly error messages.