Category Archives: Week 1

Connecting Object-Oriented Principles to UML Class Diagrams

Hello everyone, and welcome to my first blog entry of the semester!

For this week’s self-directed professional development, I listened to the podcast

SOLID Principles with Uncle Bob (Robert C. Martin) on Hanselminutes. (hanselminutes.com) Even though the focus of the episode was on SOLID design principles, I found that many of the ideas connected back to the object-oriented design principles we covered in CS-343 last week. The principles were inheritance, polymorphism, encapsulation, and abstraction, and also tied naturally into our current topic of UML class diagrams.

Summary of the Podcast

Here I am just going to give you guys a tiny summary of the podcast. It’s about 45 mins.

In this episode, Scott Hanselman interviews Robert C. Martin, known as “Uncle Bob,” about how object-oriented design principles shape the flexibility and maintainability of software. He explains why well-structured code allows systems to grow and adapt, while poor design leads to fragile, hard-to-maintain projects. Uncle Bob also emphasizes the importance of thinking carefully about class responsibilities and relationships early in the design phase, which is exactly what UML class diagrams are meant to capture.

Why I Selected This Resource

I chose this podcast because it offered a professional perspective on how design principles go beyond theory and impact real-world software. Since we just studied the four pillars of OOP and are now practicing UML diagrams, I wanted a resource that would help me bridge those two areas. The episode did exactly that: it showed how principles like abstraction or encapsulation are not just coding rules but also influence how we design and visualize systems.

Personal Reflections: What I Learned and Connections to Class

Listening to Uncle Bob made me reflect on how the four OOP principles are deeply connected to UML diagrams:

  • Encapsulation: In diagrams, private attributes and public methods show how data is protected yet accessible through controlled interfaces.
  • Inheritance: The “is-a” relationships in UML are not just arrows; they communicate how subclasses extend parent classes without duplicating logic.
  • Polymorphism: Method overriding and dynamic behavior become clearer when you see how subclasses can stand in for parents in a diagram.
  • Abstraction: Interfaces and abstract classes in UML help highlight shared behaviors without tying designs to specific implementations.

What stood out to me was how Uncle Bob framed design decisions as long-term investments. A UML diagram isn’t just a class picture, it’s the foundation for whether the software remains adaptable or becomes rigid.

Application to Future Practice

Going forward in CS-343, I’ll use these insights to strengthen my UML class diagrams. I plan to treat encapsulation, inheritance, polymorphism, and abstraction as a checklist when building diagrams. For example, when defining relationships, I’ll ask whether inheritance truly makes sense or if abstraction through an interface is better. These habits will not only help me in this course but also in future projects where design clarity and flexibility are essential.

Citation / Link

  • Hanselman, Scott. SOLID Principles with Uncle Bob – Robert C. Martin. Hanselminutes Podcast, Episode #145, January 5, 2009. Available online. (hanselminutes.com)

This resource helped me connect the four pillars of object-oriented programming we studied last week with the UML class diagrams we are now practicing. It reinforced that principles and diagrams go hand in hand, shaping how professional software is designed and maintained.

From the blog Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Introduction(CS-343)

Hi, my name is Jamaal, been a while since i made a blog but coming back to it and getting in the grove of things especially for CS-343, hopefully this will be an enjoyable semester when it comes to learning about software construction/design and architecture .

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

LeadingAgile SoundNotes: an Agile Podcast

Blog Title: Aligning Product-Driven Organizations with Customer Experience: Key Insights

This week, I listened to a podcast titled “How to Align Your Product-Driven Organization to the Customer Experience.”  The episode goes into and explores the challenges that product-driven companies face in ensuring their offerings truly meet customer needs. It explains in detail how organizations can align internal processes and product development strategies in concert with the overall customer experience and emphasizes the importance of both understanding and responding to customer feedback throughout the product life cycle.

The host starts off by discussing the gap that often exists between a company’s internal product focus and what customers actually want. They explain how organizations can get caught up in their own innovations, losing sight of customer pain points. The podcast stresses the need for continuous customer engagement, using both qualitative feedback and quantitative data to drive product decisions. They also highlight the role of cross-functional collaboration, urging teams across departments to work together to create products that not only function well but also deliver real value to users.

I chose this podcast because it directly relates to our course discussions on systems thinking and customer-centric design, both of which are crucial in software development. This points to a greater and broad development process: aligning internal systems with customer’s needs externally. More particularly, I felt that the guest speaker has done a very good job in bridging the gap between product innovations and customer satisfaction, a very crucial gap in most of the tech-driven industries today, including software development.

The one important thing I took from the episode has to do with how significant it is to assess products from a customer’s perspective. This is something that up until this point I had considered in terms of features against functionality. In this podcast, it helped me understand how important it would be to always reassess if those features actually impact the user experience. I also liked the talk about cross functional teams because it helped me confirm that successful collaboration among different departments brings much better results for any product. 

With my understanding now, using what I’ve learned can be used to integrate  into my approach to project work. Whether it’s in software development or product management, understanding the customer’s journey will be key to delivering value. I now see the importance of continuous feedback loops and how integrating customer experience into every phase of development can lead to better, more successful products. This episode has given me a fresh perspective on how to bridge the gap between product design and customer satisfaction, and I’m excited to apply what I’ve learned in future team projects.

Link to Podcast: How to Align Your Product-Driven Organization to the Customer Experience

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

WEEK 1 | Employing Agile Methodology In Scrum Master Role.

Article URL: https://clickup.com/blog/scrum-master/

The article chosen, written by the PMO Team, group responsible for moving the needle across various projects at ClickUp, discusses the vital job of a Scrum Master lies in promoting teamwork, eliminating roadblocks, and making sure execution of Agile principles to achieve successful project management !! The article is called “How to Become a Scrum Master: Skills, Tools, and Tips”; in essence, examines the duties and significance of a Scrum Master. The Scrum Master promotes dialogue among stakeholders, the product owner, and the development team while emphasizing the aim of constant enhancement. I personally was interested in this article as it applies to the agile methodology. Agile has been a topic of discussion in our lectures in the past couple of weeks and has been greatly employed in our POGIL activities. To add on to the Scrum Master lesson we had this past week, it was pivotal to come to an understanding of how all this applies together.

I chose this resource because it offers a thorough and understandable summary of the Scrum Master’s responsibilities, which is in line with my studies on Agile techniques and project management in CS-348. I found the article to be very helpful in helping me better grasp Scrum and other Agile methods because it breaks out details of the role in a straightforward way. 

I could relate to the blog post’s topic on a number of levels. I had some misconceptions regarding the function of the Scrum Master, which it cleared up first. I had kind of thought of the Scrum Master as the team’s “administrative” position before reading this. But the article made clear how much more dynamic this position is, needing the person to be a servant + leader who continually strikes a balance between the team’s requirements and productivity while preserving Agile principles. The focus on the Scrum Master as a facilitator rather than ‘traditional’ manager was what really caught my attention. The differentiation matters because it shows how the Scrum Master, instead of assigning tasks, enables the team to self-organize. With this discovery, my perspective on leadership in Agile settings has completely changed. I now see that good leadership is about empowering people to perform at their highest level, not about having control over them.

This resource has taught me that becoming a Scrum Master is more than just knowing the fundamentals of Scrum. It also involves combining soft skills like empathy and communication. This understanding will change the way I handle Agile project management from now on. For example, I now see how crucial it is to maintain a collaborative atmosphere where team members feel motivated and ready to take responsibility for their work. In order to create a positive team environment, I will continue to work on cultivating my assistance techniques and look for roadblocks that might prevent development.

From the blog CS@Worcester – Just A Girl in STEM by Joy Kimani and used with permission of the author. All other rights reserved by the author.

What is Technical Debt

The Future you Problem

Photo by cottonbro studio on Pexels.com

Hello and welcome to a new week on this beautiful blog of mine. Today is a topic that is of interest to me and possibly everyone reading this. It could also be something you ran into during a coding project. It is called Technical debt, which is the concept of delaying or omitting work to complete a project but cause more work to do in the end. 

Let me give you an example that I have dealt with, and that you may have also dealt with. So you got a coding assignment to do right and that deadline is coming fast. So you set out to do it in the quickest and easiest way possible without a care for code layout or etiquette, it is just you working on it after all. The next day, you think to yourself that you may need to rework some facets of the code to make it run better or make it look neater. You then open up the project and look in horror at the mess you made and realize that it would take more time and effort to make it neater or run better than it would be to just continue on and get the project done. That is technical debt and yes it accrues interest.

The example was more personal and not that bad when you realize that the only price you paid is something you can’t stand to look at and also something that will take a long amount of time to fix. Like I said before it is just you working on it and as long as it works it’s fine…but what if you weren’t alone, say what if you were working in a team of 2 or 4 or perhaps a whole company amount. Then we have problems. Cause not only the debt is put upon others, but even money can be a problem if it is a company involved. 

There is also types of technical debt. Planned Technical Debt is meant to establish one presence in the market or gather feedback from customers, kinda like prototyping from my understanding. There is also Inadvertent Technical Debt when the developer is unsure of market requirements or aware of the architecture. 

Many things can cause technical debt to happen, such as poor management or the code not being reviewed well enough.  So to avoid such things it’s a good idea to 

  • Understand the Requirements
  • Understanding Decision Consequences
  • Supervising the Process

So be careful when coding a project as it may come to bite you in the future, so take into consideration the future you and help you out.

Be a Better Dev. (2020a, October 5). What is Technical Debt? (as a software developer). YouTube. https://youtu.be/2nDxKYIajoU?si=crpLGeoCewYZ_kEj

Eye on Tech. (2020b, October 7). What is Technical Debt and Why Does Tech Debt Matter?. YouTube. https://youtu.be/cdzUXv8SpjY?si=FHZ0Vl6ZVkhuSNeE

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Week 1: Object-Oriented Design Principles

Sunday, September 15, 2024

This week I was introduced to Object-Oriented Design Principles. In this week’s blog, I will be discussing what object-oriented design principles are and how these principles help with creating software so that it is easy to maintain.

The Medium blog post by Ravi Patel “Understanding Object-Oriented Design Principles” offers an overview of major object-oriented design principles and how they help to the creation of successful and maintainable software. Object-Oriented Design (OOD) is a software design methodology that views the program as a collection of interacting objects, each representing an instance of a class. Ravi goes on to discuss the fundamental principles, encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is the process of grouping data and methods that operate on it into a single unit or class while restricting access to certain of the object’s components. This aids in concealing the internal state and requires all interactions to be conducted through an object’s methods.

Abstraction is the process of simplifying complicated systems by modeling classes based on key traits and behaviors, while obscuring unneeded information. This focuses on an object’s actions rather than its methods.

Inheritance allows a new class to inherit characteristics and methods from an existing class, enabling code reuse and establishing a hierarchical connection between classes.

Polymorphism allows objects to be viewed as instances of their parent class rather than their own. This enables the use of a single interface for a broad range of activities, increasing code flexibility and extensibility.

I chose this blog post because it helped me understand the principles better. After this week’s reading I now understand that object oriented principles is a theory that helps developers in how to think about and build code that is easier to work with, simpler to understand, and requires less maintenance overall. When working on my POGIL activity with my team this week, there was a question that asked us to define the principles without looking them up. We defined the principles as follows:

Abstraction is simplifying code
Encapsulation is adding code to already existing code
Polymorphism is many forms of code/methods
Inheritance are classes and their super classes and constructors

Our definitions were not entirely wrong. We could gather what each principle meant to an extent. I see myself applying these principles in my future projects. It would help create readable code that can also be modified easily as needed. This week’s material made me understand that not all long code is helpful. The simpler the code is the better it is for the next developer to read it. When I usually code, I add a lot of unnecessary code that does not need to be there. I hope to improve my code writing skills as I learn more.

Blog link: https://medium.com/@ravipatel.it/understanding-object-oriented-design-principles-0c1e48207c89  

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

Psychology in Software Development

This week I discovered a blog that caught my attention. The blog discusses the incorporation of psychology into the process of software development. Spending extended periods seated, analyzing codes, searching for logical operations and function calls can exhaust our cognitive abilities. The fatigues could lead us to feel cloudy and have poor resolution. It goes deeper into the mind of a software developer mind on how one’s retain information, problem-solving approach, perceive the behavior and structure of what they’re building. It introduces study concept such as spaced repetition and interleaved practice that have been proven to enhance a person to learn new programming languages or frameworks. I believe that integrating psychological insights into software development can help enhance both individual mental well-being and professional skills.

The blog has eight topics, one of the first paragraph of the first one said,

“The project’s outcome hinged not on the technical challenges but on the interplay of personalities, communication styles, and the leadership structure within the team”.

“A team that communicates openly and respects each member’s input is more likely to solve problems effectively and innovate. On the other hand, a team mired in unresolved conflicts and poor communication can derail even the most promising projects.”

“A team that communicates openly and respects each member’s input is more likely to solve problems effectively and innovate. On the other hand, a team mired in unresolved conflicts and poor communication can derail even the most promising projects.”

“Linking these psychological insights to Agile practices offers a fascinating avenue for enhancing team-based methodologies. Agile’s iterative approach and emphasis on collaboration are well-suited to leverage the strengths of a psychologically savvy team.”

While managing my team during group activities on Methodology, I believe it is more beneficial for everyone to feel comfortable being their authentic selves rather than feeling anxious and reserved. I think the idea of Agile practices can assists them in expressing their ideas and feeling at ease within the group. Continuing to utilize Agile methods can result in increased efficiency and effective communication within a team to meet project deadlines.

“I recall an instance where a single line of feedback transformed a junior developer’s approach to coding. It wasn’t my code review that pointed out the errors; it was my remark about his unique problem-solving skills that made his eyes light up.” I concur that helping one another to solve a problem or code in an easier way because everyone have different background with coding. Therefore, feedback and mentoring is crucial when it comes to coding. One person code could load faster and less complicated than another. Positive reinforcement can amplify a person’s strengths.

Reading this blog helps me understand how psychology is integrated into software development. All of these aspects, such as team-work, leadership, problem-solving, cognitive biases, feedback, and coaching, can be advantageous when viewed through a psychological lens. It motivates us to improve ourselves and others by helping each other enhance our skills and cognitive abilities. Where we find inspiration daily.

Blog URL: https://betterprogramming.pub/integrating-psychology-into-software-development-c5f79fc8019e

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

(Week-1) Agile and Software Development

Agile is a set of values and principles that software developers and/or managers use to encourage a positive work environment that is efficient, and promotes a successful workflow.  Agile is becoming the gold standard for software development and programming, because it is inherently based on collaboration.  Not only does it encourage intense collaboration with members of the development team, but also the customers they are making the product for.  A core tenant of Agile is to not only keep the team on the same page, but also stay transparent with the customer and accommodate their every need with the product.  Here are some important values and principles Agile is based on: “Working software over comprehensive documentation”, “Simplicity”, “Responding to change”, “Customer collaboration”, “Human communication”, and last but not least: “Continuous attention to technical excellence”.  These aren’t the only values, but they are some of the most important ones. 

“An Ultimate Guide to Agile Software Development” is an informative video about Agile Software Development, by the YouTube channel Invensis Learning.  In the video, the narrator discusses how Agile is beneficial for teams specifically in the Software Development field.  They describe Agile Software Development as a “set of iterative software development methodologies in which requirements and solutions arise from collaboration among self-organizing cross-functional teams”.  This is very important to understanding Agile, and its uses in the workplace.  Agile allows for teams working on different parts of a project to stay on the same page, and not get ahead of their peers, while still having room for improvement and disagreement.  They also go on to explain how a company following Agile doesn’t necessarily mean there isn’t a manager coordinating these things, but it suggests that each sub-group should be able to handle their problems on their own.  The video also discusses the “Agile Software Development Life Cycle”, which touches on how Software Development teams should roughly plan out their work for a product.  The cycles can differ from company to company based on the amount of employees, type of work, customer expectations, etc.  But, the values and principles should stay the same to maximize Agile efficiency.  The Agile Life Cycle follows six important steps, Concept, Inception, Iteration, Release, Maintenance, and Retirement.

To sum up today’s topic, Agile is a set of values and principles primarily used by software developers to make the workplace much more efficient and stress-free.  Agile promotes customer collaboration, and in-house collaboration with peers to ensure the product is as perfect as possible.  Over time, most software development companies will come to develop these principles, as they have been proven to be one of the best work strategies.

LINK TO VIDEO: https://www.youtube.com/watch?v=Evl5f2CnR08

  • Elliot Benoit

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

The New Methodology – Week 1

This blogpost by Martin Fowler was very interesting! It gave a very thorough and comprehensive look into what makes the agile methodology so different from older methodologies, which were very bureaucratic and abrasive when it came to change. It also showed why the principles of the more flexible, adaptive agile methodology helped to give more freedom to the developers and helped to create a better product for the developer’s clients. Reading all this put it into perspective for me how I will most likely be using this methodology in the future when I eventually go out to begin working and how this would really help to tighten up a team’s workflow and give them a better ability to put out a quality product. I really liked how as the post progressed there was a sort of small history about agile and how this blogpost was originally actually a means of pulling together most of the original ideas for the agile methodology in the past. I also understand now that agile really is just a perspective you need to have while working with a team and for a client that will help you to maintain a positive relationship with customers and maintain an efficient team. In the future I can assuredly see myself being apart of or using this methodology to develop software as it seems to be much more effective than older methods. The only thing I need to really look forward to is actually attempting to use the methodology as I don’t really have an understanding for how it would actually work or flow in practice. In essence, I think I picked this most of all because I still had questions about agile that have thoroughly been answered now, but I overall I hope for a chance to give it a try eventually in the future.

Summary: An in-depth discussion examining the difference in principles between the different methodologies of software process and an essentially original look at how agile developed and its methods, while also giving a sort-of mini history about agile and what it meant and means to developers.

Reason: I wanted a better more all-encompassing understanding of agile as I feel like I had heard this term outside of the course before, so I investigated it and came across this blog-post that seemed like it had a very detailed examination of it.

Blog Link: The New Methodology (martinfowler.com)

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

GUI Architectures – Week 1

Looking back at this blog post it is a bit outdated, being posted nearly 2 decades ago but I still feel like it has a lot of quality information within it that can still be used today. I learned about several different architectures and their patterns that I thought were rather interesting. It was still a little over my head with a lot of jargon I didn’t understand, such as “Forms and Controls” and “Model-View-Controller” which is an apparently highly misconstrued architecture, that I had to look up, but I think this gave me a good look into what I can learn more about and where to direct my attention. I think in the future after I’ve learned some more basic architecture and design concepts, I’ll really be able to apply them and understand them more. Also, I’m a lot more interested in seeing more front-end things related to GUI and the process of developing a quality and useful GUI for a user. Now looking back at myself a little bit, reading this has really cemented for me how much I don’t know about the entire software development process. It truthfully shows me how I need to really pay attention and really work harder at developing my knowledge in the field as most of the blog post was entirely new to me and things I had never heard before which gets me excited about learning more! Also, all of the diagrams in the blog post were really neat and had a great effect in helping me understand the points of each pattern, so this has kind of helped me to understand how useful UML diagrams are and would be for designing and putting a program into and understandable and digestible format that makes it really simple to at a glance get what’s happening. I do think for my next blog post I may need to pick something a bit more my speed.

Summary: An interesting exploration of various architectures for GUI design and detailing their features as well as their underlying patterns within the architectures. Also is a sort of “intellectual history” of these varying GUI architectures.

Reason: I wanted to learn a bit more about GUI’s and how they work, this really details an almost historical record of UI development and how they work underneath. It also contains plenty of diagrams and detailed explanations that really helped me to better understand it.

Blog Link: GUI Architectures (martinfowler.com)

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