Category Archives: Quarter-1

How to become a SOLID software developer.

By Petraq Mele

Hello again to those reading this blog, this time I want to talk about an extremely topic relevant in the programming atmosphere, that being a concept known as SOLID. I managed to find a great section written by Manoj Phandis on these principles.

SOLID is an acronym of five OOP design principles designed to help make it more understandable, flexible, and maintainable.

What are the main 5 design principles?

SINGLE RESPONSIBILITY PRINCIPLE: This principle states a class should have one, and only one, reason to change. Lets take an Animal class example, as opposed to the animal class having a sound and feed parameter, separate those responsibilities into separate classes.

Some benefits include:

  • more readable, that is easier to understand
  • less error prone
  • more robust
  • better testable
  • better maintainable and extendable
  • maximizes the cohesion of classes.

OPEN CLOSED PRINCIPLE: “Open for extension” means the behavior of a module can be extended. “Closed for extension” means when we are adding/extending a modules behavior it should not result in changes to a modules source or binary code.

Demonstration of the Open/Closed Principle in object-oriented programming.

An example Manoj gives is a credit card company wanting to introduce a new preferred credit card product with double reward points. Instead of using conditionals, you create an extension via implementation inheritance or interface abstraction.

LISKOV SUBSTITUTION PRINCIPLE: LSP states functions that use references to base classes must be able to use objects of the derived class without knowing it. For LSP compliance we need to follow some rules that can be categorized into 2 groups:

  • Contract rules
    • Preconditions cannot be strengthened or weakened in a subtype
    • Invariants must be maintained
  • Variance rules
    • There must be contra-variance of the method argument in the subtype & be covariance of the return type in the subtype
    • No new exceptions can be thrown by the subtype unless they are part of the existing exception hierarchy.

INTERFACE SEGREGATION PRINCIPLE: Clients should not be forced to depend on methods they do not use. Interface segregation violations result in classes depending on things they don’t need & an increase of coupling and reduced flexibility/maintainability.

Tips to follow:

  • Prefer small, cohesive interfaces to “fat” interfaces
  • Creating smaller interfaces with just what we need
  • Have the fat interface implement your new interface.
  • Dependency of one class to another should depend on the smallest possible interface.

DEPENDENCY INVERSION PRINCIPLE: This principle has two parts. The first part says high-level modules should not depend on low-level modules. Both should depend on abstractions. The second part says Abstractions should not depend on details. Details should depend on abstractions.

Part one example:

Part two example:

Final thoughts:

Overall these principles are very useful when it comes to object-oriented software development. I learned quite a good amount and I want to thank Manoj Phandis for their amazing outline of the SOLID principles, I would advise you to check them out in his website incase you’re interested in learning more.

, ,

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Blog Entry 2

Author: Yousef
Source:
Terra, John. AI for Project Management: Creating More Efficiency, Accuracy, and Better Results. UMass Global Blog, 2025.
https://bootcamp.umass.edu/blog/project-management/ai-for-project-management

Artificial Intelligence and the Future of Project Management

Artificial intelligence (AI) is rapidly transforming how organizations plan, execute, and evaluate projects. In his article, John Terra discusses the growing role of AI in automating processes that once required manual decision-making. He points out that AI technologies can analyze vast amounts of project data to identify trends, risks, and inefficiencies—long before human managers might notice them. This shift marks the beginning of a new era in project management, one where data and prediction take precedence over instinct and routine.

AI tools are now capable of predictive analytics, providing project leaders with accurate forecasts of timelines, costs, and potential risks. Terra also highlights emerging tools such as AI-driven chatbots that handle repetitive communications and machine learning models that track project performance in real time. These systems not only speed up workflow but also strengthen collaboration by giving every stakeholder access to transparent, centralized data. Importantly, Terra reminds readers that AI should complement not replace human judgment. Successful implementation still depends on leadership, empathy, and the ability to interpret data responsibly.

Why This Resource Stood Out

I was drawn to this article because it directly connects to the topics we have explored in Managing Information Systems specifically the use of technology to improve productivity, communication, and decision-making. As someone with a background in IT, I see AI as the next natural step in project management evolution. We already use tools such as GitHub and Trello to coordinate group work efficiently; AI takes this one step further by adding intelligence to those systems. Reading this piece helped me visualize how the principles we study in class can scale up to global business operations that depend on precise, data-driven project control.

Reflection and Application

Terra’s article expanded my understanding of what it means to manage projects effectively in the digital age. I learned that efficiency is not simply about speed it’s about designing systems that anticipate challenges before they occur. The idea of predictive risk management resonated strongly with me because it parallels what we strive for in software engineering: proactive problem-solving instead of reactive troubleshooting.

Another key takeaway was the emphasis on communication and ethics in using AI. Even the most advanced algorithms require human insight to ensure fairness, clarity, and accountability. As I advance in my career, I plan to explore AI-based project management tools and incorporate them into my workflow. This aligns perfectly with our program’s learning outcomes lifelong professional development and effective communication in both technical and managerial settings.

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

Improving Design Communication with PlantUML (Reposted)

Why I chose this?

So for this week’s professional development blog, i decided to go with this resource regarding UML diagrams(https://miro.com/diagramming/what-is-plantuml/#what-is-plantuml) considering we’ve been working on this in class for the better part of a few class days now. While syntax is important, I wanted a resource that went beyond the basics and emphasized best practices — specifically, how to make diagrams more readable and effective as communication tools. Which ties back to what we were doing for the classwork activity, the learning objectives of the activity we did in-class together includes identifying parts of UML diagrams, being able to connect them to Java implementation or even being able to draw the diagrams using Markdown with PlantUML.

What did I learn?
The article did help me with solidifying my understanding of the lifelines, the messages and the activation bars within the UML sequence diagrams, but in general from the article, i learned how PlantUML treats diagrams as code: by writing simple text scripts, you can generate UML diagrams consistently and efficiently. This can help out in collaborative environments, where diagrams kind of have to evolve along with the codebase. The section on best practices i find the most interesting since the article highlights that diagrams should focus on clarity over completeness.

For example, a UML sequence diagram should emphasize the key messages between objects rather than every small detail. The guide also pointed out how to use colors, notes, and layout to improve readability — so them giving pointers on how to use those things is good in case we want to make things look more pretty or neat-looking. I do appreciate the explanation of how PlantUML integrates with version control systems although it’s not something i found particularly too significant. Since diagrams are stored as text, they can be tracked and managed in Git just like source code. This makes them much easier to update collaboratively, compared to traditional tools where diagrams are static images.

Reflection and Application?

I thought it might be something i’d forget about in a month or two, i do think it helped with reinforcing the core concept that the UML designs aren’t just academic exercises that we were doing in class, it can be a practical tool for teams collaborating with each other compared to the traditional tools where it’s like the diagrams are just static images alongside the fact that it isn’t just checking a box but being able to make sure everyone understands, I guess i’d say for any future projects that come to mind, i’ll apply what i’ve learned by keeping my diagrams somewhat simple and try to make it with an audience in mind since there will be people i’ll interact with and get feedback when it comes to my PlantUML code. I also wouldn’t mind experimenting with Markdown and Git so that the diagrams can evolve with the codebase, becoming almost like living documents as opposed to a static artifact.

From the blog CS@Worcester – CSTips by Jamaal Gedeon 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.

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.