A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A brief look at UML

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled “UML Sequence Diagrams“. For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this. 

In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner isn’t an exact science, for instance you decide how much detail you want to include; something that changes depending on your reason for making one. As such, you may end up having to put more effort into making one than you originally wanted to which could offset the benefits you get from doing so. Fredrik provides insight for how he balances things out by explaining how these diagrams should be developed in tandem with the code, and how this can be done more easily.

To do this, he talks about using a tool called Mermaid, which is effectively a way to create a diagram from pseudocode. It’s very similar to a tool we were taught to use in class, called PlantUML, the key difference is that Mermaid is simpler, but faster. These “diagram as code” tools can also be version controlled which helps with keeping them updated as the code changes. 

I chose this blog specifically because it shows an anecdotal perspective of how UML is used in the real world; my main takeaways are that completeness isn’t necessarily the main priority of them, rather they need to be able to communicate (effectively but also quickly) the code, how it works, and it’s reason for existing. Shifting your priorities like this allows you to make them more quickly, which in my opinion makes them more realistic to not only create, but actively update as the project develops. Moving forward I definitely think that adopting this approach is a good idea, and probably something I will start doing.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Blog post 1

The first quarter of the semester has come to a close. In CM-348 we have gone through a number of Git and GitHub features. Learning about pushing and pulling data, as well as doing some data cleaning was a great learning opportunity. As I finish my last year of school, I am trying to look at these processes in an analytical sense because that’s what I want to do moving forward.

In my free time over the past few weeks I have watched a lot of Alex The Analyst videos on YouTube. He has provided free knowledge on what it takes to become a data analyst. From interviews, to Git, to data visualization he provides a lot on his channel for people who want to learn. This week I watched his “2 Hour Data Analyst Masterclass” video. In this video, Alex breaks down what a data analyst interview process looks like from start to finish. He discusses what kinds of technical questions to expect, the importance of storytelling with data, and how to demonstrate value through projects or case studies. He also covers common interview mistakes, like not being able to explain one’s own projects clearly or failing to connect technical skills to business outcomes. This video was very insightful, he showed his viewers what skills you really need to get into the field, and it personally showed me some things I might need to work on.

I chose this resource because it’s directly relevant to where I am in my career path, as well as in my learning. I’m starting to build my portfolio and think seriously about interviews and job readiness. Alex’s advice helped me see how important communication is in data roles, it is more than being technically skilled, also being able to explain how your work impacts decisions. This connects to CM-348 because version control, documentation, and communication are key parts of the Git workflow. I am doing a bit of projecting here, but I look forward to watching more of his videos.

From the blog CS@Worcester – Tristan CS by Tristan Coomey and used with permission of the author. All other rights reserved by the author.

Quarter 1 blog post

Blog Entry 1

Author: Yousef

Resource:
Mike Hanley, “How We Use GitHub to Be More Productive, Collaborative, and Secure.”
https://github.blog/engineering/engineering-principles/how-we-use-github-to-be-more-productive-collaborative-and-secure/

Summary

In this article, Mike Hanley, GitHub’s Chief Security Officer, explains how GitHub’s own engineering teams use the same platform they develop. Hanley highlights how GitHub continuously improves productivity, collaboration, and security through tools like Codespaces, Code Search, and CodeQL.

One of the most interesting points is that GitHub employees use GitHub to improve GitHub itself. When developers think, “Wouldn’t it be nice if…”, they can directly turn that idea into a new feature. The upgraded Code Search and Code View make it easier to explore large codebases quickly, improving the workflow for both internal teams and external developers.

Hanley also discusses productivity gains from adopting Codespaces, a cloud-based environment that allows developers to start coding instantly. The switch from local setups to cloud setups reduced startup time from 45 minutes to only 60 seconds. This change equalizes opportunities for developers who may not have high-end hardware.

Lastly, Hanley emphasizes GitHub’s strong focus on security. The company uses multi-factor authentication and CodeQL to detect and fix vulnerabilities early. What makes CodeQL powerful is its open-source nature developers worldwide can contribute to identifying security flaws, making the community stronger and safer.

Reason for Selecting

I chose this article because it connects directly to what we’ve been learning in class about using GitHub for collaboration and version control. Instead of just seeing GitHub as a tool for hosting repositories, this post shows how the company itself applies the same concepts at a global scale. It was interesting to see how features like Codespaces, which we used during the GitKit exercises, are applied in real professional environments.

Reflection

This article changed how I view software development and teamwork. It showed me that professional developers also rely on the same principles we practice: collaboration, automation, and security awareness. What stood out is GitHub’s culture of continuous improvement—treating the platform as a living product that evolves with its users.

I learned that productivity in development is not just about writing faster code, but creating systems that make everyone’s work smoother. I also realized that security should not be an afterthought; it should be built into every step of development, just as GitHub does with CodeQL.

Overall, Hanley’s article helped me see how the practices we’re learning now—using GitHub, Codespaces, and version control—mirror the real-world standards of top developers. It motivated me to take these exercises more seriously, knowing they prepare us to collaborate like professionals in the software industry.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Learning More About Design Patterns

Recently I have been learning about Design Patterns. I was specifically taught Strategic Patterns. It is a pattern that defines a family of algorithms, summarizes them, and then divides them up into understandable sections. In this type of pattern, there will always be at least one context connected to a strategy and a strategy connected to its subsections. This pattern also allows for choices in implementation which makes it perfect to have if your code needs to take any deviations due to a client. It is also good for anything that deals with a family of related algorithms, and anything that wants to avoid subclassing and conditional statements. This is good since conditional statements cause unnecessary nesting and put extra weight on the code and subclassing makes the code difficult to handle in the long run due to making it brittle. With this known, it is understandable why many utilize Strategic Patterns.

Now, I have demonstrated knowledge in strategic patterns but why stop there? There are many other pattern categories worth exploring.

To delve deeper into the topic, I used this website: https://sourcemaking.com/design_patterns

This website explains a few design patterns such as: Behavioral, Structural and Creational. It explains them in a beginner friendly manner, which is the main reason I chose it. It also defines what a Design Pattern is and the cons of using Design Patterns.

The first thing I learned about was Creational Design Patterns. This pattern focuses on class instantiation which allows you to use the blueprints defined by a class to create objects with specific states and behaviors. Let’s say you need to create a class that holds all existing employees. With class instantiation, you need to add is needed information such as name, email, department. Then, all you would need to do would be to give the employee attributes and the code would sort itself making sure that employee information would be sorted into the exact format you desire. In general, Creational Design Patterns specialize in making this a seamless process for your code.

The next thing I learned was Behavioral Design Patterns. It focuses on class objects’ communication. Sometimes one class needs information from another to initiate, terminate or do a specific task. Behavioral Design Patterns is designed for that. It possesses a chain of responsibility and makes sure each link in that chain runs smoothly. The code depends on it since if one class goes wrong, the others would follow.

To conclude, there are many ways to do Design Patterns. Each have their own purpose and specialties. It was interesting to learn about a few of them, and I wonder if I will have to utilize one in the future. Nevertheless, it was interesting to learn about.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Understanding UML

I had seen UML diagrams in previous classes, but honestly had no idea it was a language. And I also had no idea I could create my own. Working with UML diagrams in class as well as for homework has been an interesting challenge since it is a language I’ve never seen before. I searched for blogs related to UML and stumbled upon a blog by Suneel Kumar from Medium called, “Understanding UML: The Unified Modeling Language”. It provided me with a much better understanding of UML and how it can be applied to ease the process of designing code.

Unified Modeling Language

Unified Modeling Language, UML for short, is a standardized visual language used to design, document, and communicate complex systems. The creation of the language is credited to Grady Booch, Ivar Jacobson, and James Rumbaugh, who are collectively known as “the Three Amigos”. The three already had their own separate methods: Booch method, Object-Oriented Software Engineering, and Object Modeling Technique. They were combined to create the unified approach. The first version of UML was made in 1997, and the current version, 2.5.1, was made in 2021.

Diagram types

UML has many diagrams designed for different purposes. The different types of diagrams are categorized into two groups, Structural and Behavioral diagrams. Structural diagrams represent the static aspects of the system, while behavioral diagrams represent the dynamic aspects of the system. An example of a structural diagram would be a class diagram. Class diagrams are the UML diagrams that I’ve been most familiar with. It shows the classes in a system, as well as attributes, operations, and relationships between objects. Here is an example of what one would look like:

An example of a behavioral diagram would be a use case diagram. Use case diagrams capture the functional requirements of a system and show the interactions between the user and the system. It would look a little something like this:

Relationships

We touched on the relationships that UML uses a little bit in class, but the blog gave me a clearer explanation of what each one meant.

Association represents a relationship between classes and is generally shown as a simple line. As seen in the diagram below, Person and Car have a relationship since Person must drive the Car. This is shown with a simple line.

Aggregation is a specialized form of association that represents a “whole-part/has-a” relationship. In the diagram below, there is a line with an open “diamond” between Department and Employee. The open “diamond” is on the Department side and indicates that the Department is made up of Employees, but Employees can exist independently of a Department. 

Composition is a stronger form of aggregation where the parts cannot exist without the whole. In the following example, house and room are related and there is a filled in diamond on the House side. This represents the relationship as a Room cannot exist without a House.

Inheritance represents an “is-a” relationship. Child classes point to the parent class with a hollow triangle at the end of the line. In the following example, Car and Truck are both types of Vehicle, and is shown with a hollow triangle pointing to vehicle

And realization is often used to show that a class implements an interface. In this example Shape points to Drawable, which is labeled as an interface.

From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming

Hello everyone,

This week’s blog topic will be about Object Oriented Programming. I chose this topic as it is a fundamental knowledge that every programmer should know and this blog does an amazing job at explaining to new programmers while also giving good advice for experienced developers. I would say I am in the middle ground of that spectrum so this was the perfect resource for me to strengthen my understanding of Object Oriented Programming and its concepts.  

The author starts the blog by first explaining and introducing Object Oriented Programming to readers who are not familiar with it and he also lists the topics that this blog will cover giving you a great idea of the structure of the blog and also what is he going over. He explains how Object Oriented Programming revolves around two key building blocks which are classes and objects. He then shows how they work together when writing code. This is another thing that I like about this blog is that he often explains something and provides images and examples to simply it even more, thus making it easier to understand. What was a nice addition to this blog was the section where he started talking about the origin of Object Oriented Programming. This shows us how it was not created overnight, but it took years of hard work and dedication to create sucha  great innaviation. Knowing the context of how it started it also makes me appreciate the significance that OOP has. Another good point that I have to give to the author is how he compared it to procedural programming. It is kinda hard to understand why certain approaches are picked and by giving us this comparison between the two it makes it a lot easier when to use OOP. My favorite section was definitely where he talked about the four pillars of Object Oriented Programming which were inheritance, encapsulation, polymorphism, and abstraction. The explanation for each one of them were concise, and meaningful examples were provide clarifying any questions that readers may have had. The author also gives great analogies and I appreciate this a lot as it makes understanding the concepts a lot easier. My favorite example of this is when he was going over Abstraction, “Abstraction is like a laptop’s user interface. When you use a laptop, you interact with the interface (e.g., the keyboard, trackpad, and screen) without needing to know about the underlying hardware (e.g., the Processor, RAM, and Hard Disk).” 

In conclusion this blog turned out to be very beneficial for me, and I hope the same for whoever is reading this. His blog was very informative without being overwhelming and this allowed me to strengthen my foundation of Object Oriented Programming

Source:
https://www.designgurus.io/blog/object-oriented-programming-oop

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

Pros and Cons of Java

I found an article that discusses the pros and cons of Java in 2025. This caught my attention because Java is the language I have used in most of my classes. Object-oriented programming is also what we are discussing in CS-343. Java seems to be pretty versatile, and is fairly straight forward. I was interested to see in more depth what it has to offer and what it might not be so good with.

The article begins with an overview of Java as a whole. It discusses Java’s wide usage for a variety of different projects and its user friendly features that make it so widely liked. It quickly goes into the benefits of using Java. The author lists four main pros for the language: a straightforward learning process, object-oriented programming, heightened security, and platform independence. It is also mentioned how its simplicity makes it perfect for both beginners and more experienced programmers. For each main pro, the article goes into deeper detail to explain further what these benefits really mean for Java. Some interesting points in these explanations were the security features and the use of JVM (Java Virtual Machine). However, there are also the cons that come with it. The main cons listed here were performance constraints, licensing expenses, and GUI development complications. Similarly to the pros, these cons are then explained in more depth. The article’s last main section gives examples of ideal use cases for Java and some that are not so ideal. Web applications, mobile app, cloud computing and big data projects were listed as ideal use cases, where complex desktop GUI’s and alternative languages being more fitting for certain tasks were listed as times you may not want to use Java.

I found this article to be fairly interesting. Java is a language that I already knew a decent amount about, but it was interesting to learn more about it. As we learn more about Java and object-oriented programming, it is nice to know the benefits and what its strengths are. I also found it interesting that big data projects were listed as something Java works well with. Typically, R and Python are the languages most associated with data, but tools like Hadoop make it fitting for processing large amounts of data which may not be obvious to someone new to the language. Overall, it seems like Java has many benefits, and the cons seem to be minimal. I look forward to learning more about Java as I continue to use it!

https://www.netguru.com/blog/java-pros-and-cons

From the blog CS@Worcester – Auger CS by Joseph Auger and used with permission of the author. All other rights reserved by the author.