Category Archives: week15

Deep Dive: UML Diagrams

This week I’m again back at my favorite site, GeeksForGeeks. For everything I learned about in class, there’s always something GeeksForGeeks can teach me. Unified Modelling Language (UML) is just how it sounds, a language for modelling a system. It is a multi-faceted tool and in class we learned about class and sequence diagrams. What I was happy to learn however is that these two examples of UML can be separated into two categories, Structural UML Diagrams and Behavioral UML Diagrams.

Quick note: I will be summarizing this article as someone who knows what UML class and sequence diagrams are. If you do not know what these are then I would read the article yourself to get to the same starting point.

The article starts with a brief summary of what UML is before hopping into the categories of diagrams and plethora of examples of each. First up is Structural Diagrams and they include the class diagrams most people have seen, composite structure diagrams that show more detail for the individual parts, object diagrams which model how instantiated class objects interact with one another in the system, and component diagrams show how the physical pieces of a system are laid out. They are followed by the deployment diagrams visualizing all the pieces of hardware with their corresponding piece of software components and to wrap this category up we have the package diagrams to show us dependencies and internal composition of, you guessed it, our packages.

Next up is the Behavioral Diagrams, categorically separated into state machine diagrams that models a classes change over time or results from an external stimulus, activity diagrams which are reminiscent of flow charts in their depiction of the various states of a system, and use case diagrams showing the requirements for a system to properly interact with the users (known as external agents). Next up is the good old sequence diagrams, followed by communication diagrams which show similar information to sequence diagrams but in a more ‘free form’. This leads into timing diagrams that are again, similar to sequence diagram except now they are showing the constraints on time and duration. And finally we see interaction overview diagrams which are just a high-level overview of the interaction within the system.

After these types of UML diagrams Geeks For Geeks has a refresher for the OOP principles in UML that then rolls into some of the tools used to make these diagrams as well as the steps to make them, best practices, use case for these diagrams, how they fit into the Agile development mentality, some of the common challenges in regards to making UML diagrams and finally some of their myriad of benefits.

Almost needless to say, I now have a bookmark to this article and will be giving some of the listed tools a spin once I have the time. I expect this knowledge to help me in mentally visualizing a system so I can better address any problems that arise.

Link:
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/#3-types-of-uml-diagrams

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

SPRINT 6 RETROSPECTIVE

Summary

This sprint was a very important one considering what we had sought out to accomplish. In this sprint, we wanted to add many functionalities and since it was the last full sprint before the end of the semester, we wanted to address all the major functionalities we felt needed to be added before we called it a semester. Some of these tasks that was being addressed this sprint was : 

  1. Updating Offline Track Refresh Time.
  2. Documentation of work that was completed 
  3. Test Cases – UI Checkbox Test 
  4. Backend Functionalities. 

Most of the documentation was done by our team captain, since he had the most understanding of all the moving parts that was involved in the program.

What was Accomplished 

Of the tasks that was set out to be completed, we were able to complete the offline track refresh time and also the backend functionalities of the program. To make things more clear, we also documented a list of classes and files that we touched / edited and also draw a diagram of how we envisioned our additions and modifications to function within the application. Backend functionalities was tricky but we were able to write modify existing methods and function and also wrote new methods that would aid in completing the requested task. All this work was again documented and revised.  I believe the most challenging tasks through out the sprint was coming up with test cases that would evaluated and affirm the functioning of the proposed written code. I was personally in charge of this testing. From deciding to address testing, i was able to dig through many codes and files that we later had to review and revise. Every code we wrote needed some sort of testing module that would verify its status and would be used to troubleshoot should we find have any issues in the future. 

Reflections 

After this sprint, i conclude that testing although may not seem like it, is one of the tedious tasks of writing code. In order to write efficient and proper test, you need to be able to understand the logic thats already being implemented in the code then reverse the thought process and develop a new way that you can verify that the task got accomplished.  I realized that not only do you need to be able to read and understand code efficiently, you also need a creative edge that would be used in coming up with test cases and scenarios. This is because unlike coding, often test cases and implementations are unique and does not already have a laid out methods to get this accomplished. Coding requires pose and originality but i believe testing adds a touch of creativity to this paradigm. Overall it was a good sprint and i think we were able to communicate better and get a lot done. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.