Workshop 2 – Design

This describes the task for 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. You must be a course participant and logged in to see the information below.

Please use English in your models and documents. You may get international students as reviewers.

Requirements for grade 2

Design and implement a simple member registry with CRUD (Create, Retrieve, Update, Delete) functionality. Implementation (source code + “running” version), class- and interaction-diagrams are to be created and presented. The interaction diagrams should show how a model-view separation is achieved (i.e. start in the ui) and how the different requirements are met. Design and implementation should match. Save diagrams and implementation in your portfolio.

The focus is not to create a usable or fancy user interface but to have a robust and well documented design that can handle change and follows the GRASP. My recommendation is that you base your work on a console application.

OBS: It is not permitted to use any type of framework, however class libraries, api:s etc are permitted. Basically you should design and code your own application.

The following requirements are to be met:

  1. Create a new member with a name, personal number, a unique member id should be created and assigned to the new member.
  2. List all members in two different ways:
    1. “Compact List”; name, member id and number of boats
    2. “Verbose List”; name, personal number, member id and boats with boat information
  3. Delete a member
  4. Change a member’s information
  5. Look at a specific member’s information
  6. Register a new boat for a member the boat should have a type (Sailboat, Motorsailer, kayak/Canoe, Other) and a length.
  7. Deleta a boat
  8. Change a boat’s information
  9. Persistence (the registry should be saved and loaded for example from a text file.)
  10. Strict Model-View separation (The model should not depend on the view or user interface in any way (direct or indirect) the user interface (view) should not implement domain functionality)
  11. Good quality of code (for example naming, standards, duplication)
  12. An object oriented design and implementation. This includes but is not limited to:
    • Objects are connected using associations and not with keys/ids.
    • Classes have high cohesion and are not too large or have too much responsibility.
    • Classes have low coupling and are not too connected to other entities.
    • Avoid the use of static variables or operations as well as global variables.
    • Avoid hidden dependencies.
    • Informations should be encapsulated.
    • Use a natural design, the domain model should inspire the design.
  13. Simple error handling. The application should not crash but it does not need to be user friendly.
  14. Participate in the peer review process

You should have the following in your portflio and all parts should match.

  • A well tested runable 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 class diagram for the entire application, focus on relationships of the classes and important details (do not add every single attribute or operation)
  • Sequence diagrams that covers one input requirement (create member, register boat or Change Information) and one output requirement (List members or Look at member info)

Some tips on tools to create diagrams are and that seem to cover the needs we have and are quite agile. Some versions of Visual Studio has a number of tools for diagrams.

Tutorial on compiling your c# project into a self contained exe from vscode by Molly Arhammar.

Requirements for grade 3

  • Perform the requirements for grade 2
  • Expand the design and implementation to include:
    1. Simple authentication; a user must be logged in to create, change and delete information (members and boats). Not logged in users should be able to see information (list, see details and search (see below).
    2. A simple selection/search of members. That is a subset of the member should be listed, for example members with a name that starts with “ni”, members who are older than a certain age, born a certain month, has a certain type of boat etc. A design pattern should be used to solve the problem and it should be easy to add new types of criteria, that is the design should show how new criteria can be added and what needs to be changed. You do not need to implement all the above examples.

Requirements for grade 4

  • Perform the requirements for grade 2
  • Perform the requirements for grade 3
  • Expand the design and implementation to include:
    1. Data validation and error handling with user friendly error messages. The solution should avoid code duplication and be as flexible as possible.
    2. Complex selection/search of members. The model should be able to perform arbitrarily complex/nested selections of the type: “members who are born a certain month or has a name that starts with “ni” and are older than a certain age”. That is (month==Jan || (name=”ni*” && age > 18). A design pattern should be used it is enough to show flexibility on the model-side, that is you do not need to implement a view (user interface) for this. A few “hard coded” examples on searches are good enough.

Welcome to CoursePress

en utav Linnéuniversitets lärplattformar. Som inloggad student kan du kommunicera, hålla koll på dina kurser och mycket mer. Du som är gäst kan nå de flesta kurser och dess innehåll utan att logga in.

Läs mer lärplattformar vid Linnéuniversitetet

Student account

To log in you need a student account at Linnaeus University.

Read more about collecting your account

Log in LNU