This describes the task for the second examination of the second workshop, perform all the steps in order. Be sure to document all assumptions and changes you are making. Also, be sure to specify who participated in the work and be prepared to answer any questions about your model and implementation.

It is recommended to study the suggested solution for Workshop 2, and also look at the design and implementation of Workshop 3.

All files should be zipped into an archive and be in one of the following formats. plain text (i.e. different source code files), pdf or common image formats (e.g. jpg, gif, png). Do not use word documents etc. You upload your solution on myMoodle.

Requirements for grade 2

Fulfill the requirements for Workshop 2, Grade 2 with the following changes:

• No peer review. There is no peer review step for this workshop.
• Model View Controller (MVC) Architecture:
  • the Model encapsulates the business requirements, and have no dependency to, or responsibility of, View or Controller.
  • the View is responsible for low level input and output (e.g. reading from keyboard, printing in console)
  • the Controller is responsible for managing and executing usage scenarios, e.g. adding a member
• There should be at least two different types of Views. The views should differ in the following ways:
  • Language, this includes names of boat types (input and output), and units for length (meter v.s feet). All items do not need to be perfectly translated.
  • Menu Layout: the order of items in the menus should be different, e.g. Add Member as the first option vs. Compact List as the first option.
  • Menu Input: the type of input for menu items should be different, e.g. Numbers vs. Characters
  • List Layout, the order of information in the two lists should be different, e.g. Name first vs Member id first.
  • Input Order, if applicable the order of input from the view should change e.g. “Member_Name + Member_PersonalNumber” v.s. “Member_PersonalNumber : Member_Name”. This only applies if you have functions that return “multiple inputs” in one call.
  • Type of View should not affect the Model or Controller: e.g. it should be easy to add a third view. Note that it is ok (and maybe necessary) to change your current model/controller to get this working, but for a hypothetical third view no changes should be needed.
• Add a (main) menu option to change the view, e.g. from English to Swedish.
• Tip: You can draw some inspiration from the design of the BlackJack game.
• Tip: If you have a complex view (e.g. many classes) the Abstract Factory pattern applies, e.g. EnglishViewFactory and SwedishViewFactory.
• Updated design level class and sequence diagrams.

You should submit the following and all parts should match.

• A well tested runnable version of the application. For example, an .exe or .jar file, link to website etc. If it is not easy to run the application you must include instructions on how to run it.
• The source code of the application, with possible instructions on how to compile it, external dependencies etc.
• A design level class diagram for the entire application, focus on relationships of the classes and important details (do not add every single attribute or operation). You should show that you can use correct associations, dependencies, generalization/specialization and Realization UML relations between classes and interfaces.
• Sequence diagrams that cover one input requirement (e.g. create member, register boat or change information) and one output requirement (e.g. list members or look at member info)