Workshop 2 feiyu xiong

Try to compile/use the source code using the instructions provided. Can you get it up and running? Is anything problematic? Are there steps missing or assumptions made?

The executable file won't work if there is no "members.txt" from the start. So you have to create one manually. Otherwise the application crashes and it should not do that. "The application should not crash but it does not need to be user friendly." [1].

Does the implementation and diagrams conform (do they show the same thing)? Are there any missing relations? Relations in the wrong direction? Wrong relations? Correct UML notation?

Missing the relation between "Boat" and "BoatCategory". According to "UML Class Diagrams: Reference" there should be one when using enums [2]: Otherwise it looks good with focus on relationships and classes for the entire application as stated in the assignment "A class diagram for the entire application, focus on relationships of the classes and important details (do not add every single attribute or operation)" [1].

Is the Architecture ok?

The architecture is structured according to the MVC architecture. Which makes it very well organized and understandable separating the business logic from the interface [3]

Is there a model view separation?

There is a model view separtion and in the class diagram it is very clear and in the interaction diagrams there is a separation as well. In the intercation diagram the model view separation is not as clear as in the class diagram. Even though you get it eventually. In the source code it is devided in different maps to show the model view separation.

Is the model coupled to the user interface?

No, only the views and the controllers are coupled to the user interface.

Is the model specialized for a certain kind of IU (for example returning formated strings to be printed)

The model is suited to a console application since it doesn't override ToString()-functions to return formated strings for a "Member" and a "Boat".

Are there domain rules in the UI?

No they are separated using the MVC architecture [3].

Is the requirement of a unique member id correctly done?

Yes:

What is the quality of the implementation/source code?

Except for "Member"-ID being decided by "BoatId" and the application crashing when the text file doesn't exist I think the implementation has good quality.

What is the quality of the design? Is it Object Oriented?

Except for "Member.cs" having a dependency of "BoatId" when deciding an id for a member I think it is good object oriented quality with high cohesion within a class and good associations between classes.

Is GRASP used correctly?

Good encapsulation with private members accessed via getters and setters. Good use of creators [4, s.4] Cohesion is high in classes except for using "BoatId" to determine the "Member" id. The classes "HandleBoats" and especially "HandleMembers" have higher coupling than the rest of the classes. Might be a good idea to see if you really need all those relations [4, s.12].

As a developer would the diagrams help you and why/why not?

Since the focus for the diagrams was more on relations it will help me as a developer out more with that: "A class diagram for the entire application, focus on relationships of the classes and important details (do not add every single attribute or operation)" [1]. Some attributes, their types and also operations were left out because of that focus area so it won't help me much with that.

What are the strong points of the design/implementation, what do you think is really good and why?

• The really strong focus on the MVC architecture will make the solution more organized and well structured.
• Focus on relationships [1].

What are the weaknesses of the design/implementation, what do you think should be changed and why?

• Sometimes too many connections between classes that will make it harder to understand and also maintain the solution ("BoatId" and "HandleMembers").
• No check if text file exist.

Do you think the design/implementation has passed the grade 2 criteria?

If the relationship between "Boat" and "BoatCategory" is added to the class diagram and also a fix is made so the application does not crash when there is no text file from the start. Then I think the design/implementation will pass the grade 2 criteria. "A class diagram for the entire application, focus on relationships of the classes and important details (do not add every single attribute or operation)" [1]. "The application should not crash but it does not need to be user friendly." [1].

References:

1. Ohlsson T., Workshop 2 – Design, 2014-09-21, https://coursepress.lnu.se/kurs/objektorienterad-analys-och-design-med-uml/workshops-2/workshop-2-design/

2. UML Class Diagrams: Reference, 2016-10-11, https://msdn.microsoft.com/en-us/library/dd409437(v=vs.140).aspx

3. MVC architecture, 2016-04-03, https://developer.mozilla.org/en-US/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture

4. Rao D., GRASP Design Principles, 2012-12-09, https://www.cs.colorado.edu/~kena/classes/5448/f12/presentation-materials/rao.pdf