CST 338 - Week 6

UML Diagrams & MVC

I have very limited experience with UML diagrams. My professor at community college used them when teaching us about interfaces and inheritance, but I never had to make one myself. I have made class flowcharts, however, most notably this one. UML diagrams in their most technical form are generally worthless for me, but it's nice to know how to decipher them. The diagram I created for this week's assignment is about as close as I hope to ever get to an official one, but I suspect we may be required to make them again. Based on my internet readings (Reddit browsing), it seems that their usage may be rare, but some large companies do use them.

We also discussed the MVC design pattern this week (Model-View-Controller). In this model a controller class acts as a middleman between the view and the model, who should not have any knowledge of each other. The controller sends and receives data from the model and then updates the view using the received data. Its job is to make sure that what the user sees on the screen and what the computer sees in memory are the same. This is very helpful because it separates projects into different branches, making it easier to build and debug. 

Multithreading

My first attempt at multithreading occurred when I was writing an IRC client a few years ago. I realized that it was not possible to interact with my GUI while a socket connection was open. The infinite loop of the connection needed to run on its own thread. Unfortunately I failed miserably and was forced to abandon my aspirations to create a full-fledged client. A simple IRC bot would not be the same. Eventually I did learn how to use simple threads, and now I am able to implement multiple threads with synchronized methods (especially using TimerTask in Java).

Keeping Up

This week was a wild ride. What was meant to be an easy week turned into an academic nightmare. I would rather not get into the details on this public blog, but I experienced what it's like to be investigated for academic dishonesty. Fortunately the true offender confessed, but this should never have happened to begin with. I forgot an important lesson I learned just a couple of years ago.

When I was a newly promoted Corporal, I trusted my Soldiers to perform a task on their own and did not check that they correctly completed it. Although things worked out in the end, I learned to always "trust, but verify." In this case I did not verify the integrity of code that was submitted to me. Some may say that it's not my job to do so, but it sits on my shoulders knowing that my team had to go through that.