I found this assignment much harder than the first. It took significantly more time since I had to make corrections from the first assignment. I probably spent alot of time on this assignment, a trend that will probably continue given the nature of the course: thinking through systems, their connections, uses and requirements of the stakeholders. This assignment alone was probably 24 hours spent, several days putting in 8 hours or more. It is hard to manage the expectation of what to place in the assignment and time spent since analysis and design are open ended, both a science and an art.

        I struggled the most with the domain problem class diagram. I had though I captured all the objects and their interconnections in the system before starting. As I continued, more objects came to mind, making the associations harder to maintain. Thinking through my list may have helped, but I think working through the diagram helped reveal some of the objects as well. I was also not sure if 1 to 1 multiplicity was allowed or if an association class could be connected to other classes. I reconfigured both my association classes to work as shown in the textbook. Thinking of the attributes was easy in some cases, and I wasn’t sure when to make the cut off. Another issue I had was trying to make all the connections to one of the classes, since it is involved in the system to a large degree, with the most associations.

         As mentioned, more ‘things’ for the system came to mind. Identifying more classes made me realize that I may have overlooked some things in the first assignment. It wasn’t a great realization but does show the power of the iterative process. I also realized with these units and assignment that I have used a class diagram (for a single class) before in one of the other courses, just not explicitly introduced. It reinforced the idea of the models being used by others to construct the program.

         With the use case diagram, it was hard to decide what use cases the office clerk should have access to. What other non-system duties does the clerk need to attend to and how much time will they have access to the system, beyond making reservations? Do they construct the newsletter? Are they also the  “first line of defense” for when a member calls to make a complaint or ask a question? With complaints, what are the authorized to do? How much information should they have access to? I tried my best to include enough to be useful to the managers but not overreach. Obviously, interviews would help bring details that “standard job description” and “general office duties” skip over. Also, this assignment showed me why some developers choose not to do use case diagrams, as I mentioned in the 2nd discussion forum for Unit 3. It felt like it was getting out of control fast and was repeating information captured in the use case descriptions or by the class diagram. I can see doing a very quick informal one to check some basic overview, but it was hard to manage with the use cases after a while. 

         When I got the first assignment back, I realzied I needed more detail in my use cases. The proposal was suppose to be more specfic, than general. However, it was still a hurdle not to go too far and think of many exceptions and scenarios and get bogged down with too many of those and their details. In some sense I was still working with the perfect technology assumption, but it was hard not to think of what could go wrong or needed protection or support. It was also hard to separate ‘perfect’ functioning from ‘good to haves’ that weren’t also system controls, such as warning a member that there booking was almost over. I did outline a few scenarios and exceptions within some of the brief use case descriptions. I feel burnt out thinking of the use cases, scenarios and exeptions, and probably still missed a whole mess of them. It can truly never stop really.