One of the first topics we were introduced to was UML diagrams, which are diagrams that represent something, like the order or the makeup in a visual way. In class, we learned UML class and sequence diagrams. The class diagrams visualize the code files, listing off necessary information, like variables and methods, whether they are private, public, static, abstract, and can have notes for things with special cases. The sequence diagram visualizes the sequence of lines of code in main. UML was also used in making diagrams to explain the architecture of systems.

In this blog post, by Nishadha, they go into detail about types of diagrams and provide examples. UML stands for Unified Modeling Language, and is used to model “software solutions, application structures, system behavior and business processes.” There are 14 types of diagrams, which can be organized into 2 kinds, structure diagrams and behavioral diagrams. The structure diagrams “show different objects in a system.” The class diagrams and architecture diagrams belong to this group. The behavioral diagrams “show what should happen in a system.” The sequence diagrams belong in this group.

Structure diagrams are used to show the relationship between classes and/or objects in a software system. There are seven different diagrams, class, component, deployment, object, package, profile, and composite structure. Each offers something a little different from the other, but do essentially the same thing. Class diagrams show the relationship of classes in software, but object diagrams show the relationship of objects in a real life setting. Finding one to use that matches the situation you need it for is not hard. 

Behavioral diagrams are used to show how things are supposed to work. Like structure, there are also seven, use case, activity, state machine, sequence, communication, interaction overview, and timing. Each are more unique compared to each other than the structure diagrams are, but also do the same thing, showing the flow of it. The flow of logging into an account, the flow of shopping, the flow of code, etc. By visualizing the flow, it can allow you to see what is happening, spots that could have issues, and maximize it to be the best it can be. The post includes examples and templates of each type of diagram in case someone is interested in seeing more or if someone wants to use one. 

I chose this particular blog post because I did not know that there were this many types of UML diagrams. With this broad amount, I can see it being used not just for software and businesses, but for other things as well. Visualizing things out is very beneficial, allowing you to keep track of things and make things concrete, instead of just picturing it in your head. I think UML is cool, it is certainly different from what I have learned in the past, but I will use it whenever I need to. It is also not that hard to learn, making it a little bit more accessible.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Link to blog: https://dzone.com/articles/top-10-software-architecture-patterns-to-follow

Recently, we have covered a few different types of software architecture, namely Monolith, Client-Server, and Microservices. While these each have their respective use-cases, I wanted to explore more possibilities for the architecture of a software. Because of this, I have found the Top 10 Software Architecture Patterns to Follow in 2024 by Lucas Lagone. 

Lagone establishes a format to his top ten list by describing the overview, benefits, and use-case for each item. His number 1 software architecture pattern is layered architecture. According to Lagone, layered architecture (or the N-tier architecture), divides the software into several layers each responsible for their own functionalities (Lagone). This type of architecture encourages modularity, allowing for independent development of different layers of the software,  and can be utilized for a variety of types of applications (Lagone).

Lagone continues his list, discussing the rest of the architectures below:

• Serverless Architecture
• Hexagonal Architecture
• Event Sourcing
• Model-View-Controller
• Microservices Architecture (covered!)
• Service-Oriented Architecture
• Event-Driven Architecture
• Repository Pattern
• Reactive Architecture

Lastly, Lagone writes about how one can choose the right architecture for their needs, and what factors come into play. Some of these factors include the complexity of the problem domain, the project’s requirements and goals, the scalability of the project, security, team expertise, etc. (Lagone). 

I selected this resource because it is a recently written (November 2023) article that is a good reference for an updated list of software architectures currently in use. It’s a great resource that clearly gets the point across for each item in the top 10, whilst being a short enough read to be a good refresher for those unfamiliar with the information. 

Personally, I found this to be the perfect article for me to quickly learn more software architecture patterns. It doesn’t go too deep into the software jargon and terminology that only an experienced professional would know, yet it still talks to you in a way that assumes you are an educated yet learning individual. I really liked the formatting of the top 10 list, as it gave organization, purpose, and distinction to each of the items. I learned many other types of architecture, and specifically what to consider when selecting a software architecture pattern for your project/team. This is probably the most important part, as choosing an incompatible pattern for your needs could set you back even further than you were before. I hope to apply this to future jobs where I can contribute to the selection of an architecture based on this knowledge.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In the realm of web development, the importance of REST (Representational State Transfer) APIs cannot be overstated. They serve as the backbone of communication between client and server applications, facilitating the seamless exchange of data. My recent exploration of the article “Understanding REST APIs: A Comprehensive Guide” on Medium provided a deep dive into the intricacies of RESTful architecture, the principles behind it, and practical examples of its implementation.

I chose this article because it offers a holistic view of REST APIs, making it suitable for both beginners and seasoned developers looking to refine their understanding. The author does a commendable job of breaking down complex concepts into digestible sections, ensuring readers can follow along easily. The article not only covers the technical aspects of REST APIs but also emphasizes best practices and common pitfalls, which are crucial for anyone working with APIs.

One of the key takeaways from the article was the emphasis on statelessness in REST. Each API call is independent; the server does not store any client context between requests. This design choice simplifies scalability and reliability, allowing systems to handle multiple requests without the overhead of session management. Understanding this principle has reshaped my approach to API design. I now recognize the importance of making each API call self-contained and meaningful.

Additionally, the article highlighted the significance of HTTP methods—GET, POST, PUT, DELETE—and their respective roles in interacting with resources. This reinforced my understanding of how to use these methods appropriately to perform CRUD (Create, Read, Update, Delete) operations effectively. The practical examples provided illustrated how to structure requests and handle responses, making the learning experience both informative and applicable.

This material significantly impacted my perspective on API integration in my projects. Previously, I approached APIs with a surface-level understanding, often overlooking essential details that could enhance my applications. Now, I feel equipped to design and implement more robust and efficient RESTful services. In my future practice, I plan to apply these principles not just in personal projects but also in collaborative environments, where clear communication with APIs is crucial for successful integration.

In conclusion, “Understanding REST APIs: A Comprehensive Guide” served as an invaluable resource that deepened my understanding of RESTful architecture. The insights gained will undoubtedly influence my future work as I continue to navigate the complex world of web development and API integration.

For more details, you can read the article here: Understanding REST APIs: A Comprehensive Guide.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Christopher Okhravi explains in this video what a Strategy Design pattern is and how it works through some UML class diagrams and a little bit of pseudo-code as well as stopping at each point to explain each piece of the Strategy Pattern. All of this coming from a book called “Head-First Design Patterns” by Eric and Elizabeth Freeman. I wanted another viewpoint on the strategy pattern outside of class and in a more succinct form, so this video seemed like a good resource. Mr. Okhravi actually really cleared up a lot of the misconceptions I had about the Strategy Pattern in general, as the entirety of the video is essentially just one big example walking through each step of the Strategy Pattern process, even using the same example we had in class of the duck classes, although he does go into explaining each detail of the Strategy pattern thoroughly going into how inheritance is nearly as important as cohesion for this pattern. It also led to the revelation for me about not even needing subclasses and introducing the idea that cohesion was more important than inheritance with cohesion leading to more flexibility than just straight inheritance. Learning about this design pattern actually really helped to me to better understand how I would apply this when actually writing code, it also put the other design patterns we’ve learned about into a better perspective for me and kind of how powerful they really are. Other than this it also showed me that I didn’t really understand how the strategy pattern worked or what a design pattern completely was. But now thanks to this video I’ve definitely developed a better appreciation and a better understanding of how these design patterns work. From this point forward I’ll need to really have more supplemental material for every patter we learn about so I can actually interface with them properly. I think in the future I’ll really have to spend time learning more about other design patterns and their uses as these seem highly valuable to really understand and know how to use. Also, for any further delves into the other design patterns I’ll probably be going back to this creator here as he seems to have a good grasp on them and explains them clearly enough with the visual component for me to really understand it. I highly recommend giving this and his other videos a look as he sorts them into playlists for easy viewing.

Here’s the video on the Strategy Pattern.

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

This week, I am going to be chatting about the benefits of Humanitarian Free and Open-Source Software (HFOSS). Prior to class this week, I was familiar with open-source software, as I have previously integrated some open-source projects into personal projects, but I had never heard of HFOSS specifically, and had not given thought to the potential benefits of popularizing HFOSS development in an educational environment. Instead of referencing a blog this week, I am going to look at an actual HFOSS project that can be found here.

Crisis Cleanup is a platform designed to connect volunteers with individuals affected by disasters, particularly during and after events like hurricanes. This project is a perfect example of HFOSS, demonstrating how collaborative, community-driven software can make a meaningful and real impact.

One of the coolest parts of this HFOSS project is its emphasis on community engagement. Crisis Cleanup operates on the principle that local volunteers can provide the most relevant and timely assistance to those in need. By facilitating connections between volunteers and those affected, the platform enables random people to help in ways they probably otherwise couldn’t. Combine this with the fact that anybody can contribute, and now there is a unique opportunity to create a learning environment for students. Contributors can gain practical experience in software development, project management, and user interface design while working on real-world challenges. Students can also witness the immediate impact of their contributions, reinforcing the idea that their work can lead to tangible change. As we discussed in class, this seems to raise interest/appeal in computer science in groups that are otherwise generally less interested in it, which is an awesome way to get more people involved in the field.

Crisis Cleanup also highlights the importance of adaptability in software development. During a disaster, the needs of affected individuals can change rapidly. HFOSS allows for quick iterations and updates based on feedback from users and volunteers on the ground. This agile approach to software development ensures that the platform remains relevant and effective, which is crucial for a disaster relief program in particular. I think another really cool thing about this HFOSS project (and HFOSS in general) is that the Agile methodology is generally used. It makes sense; Agile is not exclusive to professional software development teams, but to see it used or even suggested for an open-source project is not what I would have guessed at first.

Personally, I have always had an interest in Computer Science, regardless of my awareness (or lack thereof) of HFOSS. I have not yet contributed to any projects of that nature. Moving forward, maybe I will find one to contribute to on my own, now that I know how much they can help people. Overall, I think they are an excellent way to learn/enter the field of Computer Science, and I would love to see more educational environments centered around HFOSS development and projects like the Crisis Cleanup project.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

This week, I am going to discuss the function and design of a Simple Factory pattern in Object Oriented Programming. At a very high level, this allows a programmer to centralize and encapsulate instance creation functionality into one class, as opposed to having many different classes (or your main class) depend on a large number of different classes. In my opinion, this is particularly useful when designing code that uses the strategy design pattern, as there will be objects for every concrete strategy, and many dependencies will be created. It is much easier (in at least those instances) to encapsulate all of those dependencies and creations into one class, a factory, and have that factory be dependent on all of the classes instead.

These principles are highlighted well in this blog, which provides a use case to demonstrate the usefulness of a factory. In this post, the example used is an implementation of a creature factory (admittedly less cool than a duck factory). Before implementing a simple factory, the main class is responsible to create and instantiate different creatures, and they can be created from anywhere in the code. This works, but is poorly designed, as we have discussed in class. Any time you want to make a change to the way a creature functions, for example, you might have to go edit the code in a ton of different places, and your UML diagram might just look atrocious. To address these design flaws, we can introduce the Simple Factory pattern, which centralizes creature creation logic into one dedicated class. This factory handles the instantiation of various creature types, simplifying our main class instead of scattering creation logic throughout the code. Whenever we need a creature, we call a method on the factory, which returns an instance of the requested object.

The blog example creates a CreatureFactory class with a method create(CreatureType type), which accepts the desired creature type. Inside this method, we use a conditional statement to return the appropriate creature object based on the input. For example, if we get WEREWOLF we instantiate a Werewolf object. If we want to add a new creature type, like Phoenix, we just create a new class for it and update the factory method. There’s no need to search through the entire codebase for instances where creatures are instantiated.

I admittedly don’t do a lot of object oriented programming, but the principle of using a factory makes perfect sense to me, and is something that I do and will continue to do going forward. Centralization of creation looks clean, performs clean, and makes sense. I didn’t really get into this, but it also may be extremely useful for OOP languages that do not have automatic memory management like Java does. You could also centralize the destruction of objects, possibly allowing for efficient tracking and memory allocation/deallocation.

From the blog CS@Worcester – Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

The blog post I’ve chosen is all about PlantUML diagrams and how they can be used in ways to help your coding. The author writes about why diagrams can be useful for seeing things visually in a text heavy environment like coding is. There are many advantages to representing code in a diagram. Making the program abstract and only focusing on the process of how each thing should work with the others helps to focus on concepts rather than the implementation and actual workings of the code. There are also many types of diagrams, such as sequence diagrams that show what events take place over time, a use case diagram that shows what different levels of users are able to do, class diagrams that detail different objects’ construction, activity diagrams that can show workflow, and others. PlantUML is able to be used in many different ways for many different scenarios. There are sometimes problems that PlantUML cannot solve in the most elegant way, as the author describes, but there are alternatives and some problems that PlantUML was not designed to solve.

I think this blog was helpful to read through and see just how versatile PlantUML diagrams can be after learning about how to make them in class. Another benefit to diagrams that the blog didn’t go over, but we did in class was being able to find potential problems in the code before you even type anything which can save a lot of time. I think that using UML diagrams more often can help me with coding as having a diagram that gives me a top-down view would be helpful to look at instead of scrolling through a wall of text to find what I need to do next or how I can improve my code. I sometimes find that I can overcomplicate some sections of my code and having a written out simplified plan to look back at will help me code with more focus and also help with encapsulation which I don’t do as often as I should.

After reading this blog I will be more aware of what situations could be helped with a PlantUML diagram and make one to keep me focused on the structure and entire scope of the program. There are also ways to use diagrams in order to show processes that I haven’t used yet or have talked about in other classes which could be a good tool to use in the future to explain and show complex abstract processes.

PlantUML Diagrams – Matt Hayes

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

In the world of computer science, especially for those new to programming, concepts like design smells and technical debt can seem daunting. However, grasping these ideas is crucial for building sustainable software. Design smells are indicators of potential problems in your code, such as overly complex structures or poor naming conventions. Technical debt, on the other hand, refers to the compromises made during the development process that can lead to greater issues down the line, akin to borrowing money that needs to be paid back later.

I recently came across the article “Understanding Technical Debt” by Tom Smith on Medium. This piece breaks down these concepts in an approachable manner, making them easier to understand for beginners. Smith discusses common design smells, such as “Long Method” and “Feature Envy,” and explains how they can accumulate into technical debt if ignored.

I chose this article because I believe it provides a solid foundation for understanding these concepts without overwhelming beginners with jargon. As I embark on my journey in computer science, I find it essential to learn about the long-term implications of my coding decisions. Smith’s article highlights the importance of recognizing design smells early on, which resonated with me as I often focus on getting things done rather than considering the quality of my code.

What I learned from the article is that design smells serve as early warning signs. For example, if a method is too long or complex, it may indicate that it’s doing too much and should be broken down into smaller, more manageable pieces. This insight has made me reflect on my past coding experiences, particularly a group project where we rushed to implement features without thoroughly reviewing our code. The result was a project that became difficult to manage and understand. I realized that by overlooking design smells, we inadvertently added technical debt to our project.

Moving forward, I plan to apply this knowledge in my coding practice by adopting a more mindful approach. I want to prioritize code quality and regularly check for design smells as part of my workflow. Implementing practices like peer code reviews and refactoring sessions will help ensure that my code remains clean and maintainable. I believe this proactive approach will not only enhance my skills but also contribute to a more positive team environment where everyone is encouraged to uphold coding standards.

In conclusion, understanding design smells and technical debt is vital for anyone starting in computer science. By paying attention to these indicators, we can write better, more maintainable code. I highly recommend reading Tom Smith’s article for a beginner-friendly introduction to these essential concepts.

Resource:
* Fowler, M. (n.d.). Technical Debt and Design Smells: A Practical Guide. Retrieved from Martin Fowler’s website.

* Smith, T. (n.d.). Understanding Technical Debt. Medium. Retrieved from Medium.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Link to blog: https://developer.ibm.com/articles/an-introduction-to-uml/

To start off the new semester and new course, we’ve been learning, discussing, and practicing with UML diagrams, or Unified Modeling Language diagrams. These diagrams are great ways for software developers and companies to visualize the structure of programs, large or small. There are many different types of diagrams, and we’ve mainly covered Class Diagrams and Sequence diagrams. 

Although I am unsure about the popularity and usage of UML diagrams in professional environments, I believe they can be beneficial to the organization and cleanliness of a team’s code, for it is to be written after it has already been structured and designed. The article I chose today is one by Donald Bell on IBM, and it discusses a few types of UML diagrams with some background information on each.

Bell introduces a new topic to the audience as well as anyone should: with some background information. He states the creation of UML was to model computer applications and ensure that anyone who understands UML diagrams can efficiently, accurately, and productively contribute to the project. 

The first UML diagram covered is the Use-Case diagram. Such diagrams are utilized to help readers understand the interaction between the program and its users. There can be many Use-Case diagrams for one program, but they are more so used to highlight the essentials. Bell describes how to create this type of diagram so that it is easy to understand.

The second UML diagram covered is the Activity Diagram, which shows “the procedural flow of control between two or more class objects while processing an activity” (Bell). Bell believes the best-case scenario for this type of diagram is for more business-oriented visualizations, such as how a company wants to operate at a higher level. These types of diagrams are not as technical as other diagrams which makes it easier to understand for non-programmers (Bell).

The last UML diagram Bell covers is the Deployment Diagram, which shows the physical representation of a software system. This would mean user computers, databases, websites, etc.

I selected this article because it covers a few UML diagrams that we haven’t discussed in class, and it is important for software developers to have some UML proficiency.  This would be a beneficial skill to have at a new job, so you might understand the codebase faster. IBM is also a very credible company in the software industry which is why I chose an article from their website.

The content of the resource was presented in an understandable way for someone with a little bit of software knowledge. I enjoyed learning about the background of UML and its creation, along with the three types of UML diagrams that were listed and described. I hope to use such knowledge at a new job that may use UML diagrams so I could provide more productivity in a shorter time rather than taking too much time trying to understand the codebase.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.