This assignment has proven to be the hardest by far and completely threw me off of my previous impressions of this course. I also seem to find major errors in my previous assignments as I progress into new assignments. 

The most important thing I took away from this assignment/ Unit 5 and its associated readings was that in our Design Class Models, when using aggregation and composition in our models, we do not reference the object it contains via a foreign key like we would in a relational database; instead, we are thinking about object references in a programming language. The textbook shows the example of a customer who makes a purchase. There is a customer object and a sale object. The customer has a field called mySale, which is not a foreign key to the sale object, but an actual copy of the sale object. From knowledge from my Java course, we use a hard copy, which recreates an exact instance of this sale object inside of the customer object, instead of just passing a reference to the sale object using a soft copy. A soft copy results in a security hole in the program, since we would be passing in a reference to our object. Once the location of that object is known in memory, the object’s data becomes vulnerable.

 The most important concepts I learned about design from this unit were coupling and cohesion. When I first began programming, I was unaware of the utility classes that were needed to keep the problem domain classes cohesive. I was writing many functions that would not be directly related to a class. These functions/methods should have been moved to a controller. Separating the classes into a hierarchy allow the system to be much more maintainable and simpler to design.

I finally took the time to learn Visual Paradigm. It’s actually rather simple to use — just some documentation searching is necessary. I found it easy to create the Design Class Diagram with it. Another really good program I found was Lucid Charts. The Sequence Diagram (and really just systems design principles) has been difficult for me to learn; modelling basic interactions is simple, but understanding how to design the interactions between the objects in the car sharing IS is difficult. With cohesion and coupling in mind, I try to design the system so that the objects perform their specific functions and the delegation and coupling is handled by the controller. I found the examples in this part of the textbook incredibly difficult to read. These modelling activities are intuitive activities, but reading such painstaking material is very difficult. I just can’t understand how we are supposed to pass in a vehicle to the reservation system. Do we pass in a vehicle object, or do we pass in a reference to that vehicle object? And how is the reservation supposed to relate to the vehicle? Is it composition? If the owning object, the Reservation Object, is destroyed, then so are its contained objects. Since we don’t want to destroy the Vehicle object elsewhere in our system if that Reservation object is destroyed, that indicates that we should be making a hard copy of the object inside of the Reservation Object.

Another confusing aspect I found while creating the Sequence Diagram is that we are using a Member class within the diagram, which is to represent the member object that passes in the system input message of makeReservation. After much wondering how to model this, I saw the example in the textbook. This can be seen in Figure 11-12 on page 342. Even though there is a member object that represents the member actor who uses the system, the controller can still interact with the member class in the Sequence Diagram. 

The other problem I encountered was how to use the Inventory Controller, if at all. My original thought was to use it at two different times: the first as a class wide report system to see what vehicles are available for a reservation on a given date (some may discard this use case completely); then again to make sure that the vehicle is still available just before the reservation object is made. The other approach would be to use an InventoryItem class visible to each Vehicle object like they do in the text book. I don't consider this a solution, which is why I have included this in my blog post. After reading over many other's reflections on this assignment I feel that a lot of people are wondering what the best design pattern is for this system.