This is my first post for now, will be back with more in the future.
From the blog CS@Worcester – Cam' Blog by Cameron Johanson and used with permission of the author. All other rights reserved by the author.
Category Archives: CS-443
Apprenticeship Patterns – Chapter 1 and Introductions to Chapters 2–6.
I felt like Apprenticeship Patterns was different from other technical or programming books I’ve read. It wasn’t really about coding languages or tools; it was more about how to think, grow, and become a skilled software worker. The most interesting thing to me was how the authors talked about software development as a craft that needs time, patience, and humility to learn, not as something that can be done fast.
I thought it was really interesting that being a trainee is not seen as a weakness. Before reading this, I often felt like I had to “know everything.” This was especially true in tech, where everyone seems to be expected to be sure of themselves and have a lot of experience. The book taught me that being honest about how much I still need to learn is a skill. The thought of beginning as an apprentice and working my way up to success made me feel better about where I am in my journey.
Making the point of learning new things throughout life was another part that really made me think. It says in the book that learning doesn’t end when you get a job or a degree. This has changed the way I think about my future job. I used to think of graduation as the end, but now I see it as the start of always getting better. I also thought about my own habits and how I can be more deliberate about learning, practice, and asking for help.
In some situations, I don’t agree with how great the apprenticeship plan sounds. In fact, not all workplaces have mentors or an atmosphere that helps people learn. The ideas are good, but I think it might be hard to fully use them in workplaces that are too busy or don’t offer enough help. Still, I think the way of thinking that the book talks about can be helpful even when things aren’t going well.
The beginnings of the chapters that were most useful to me were the ones that talked about growth, duty, and personal development. These ideas are useful not only for making software, but also for life, school, and work. Overall, the reading changed the way I think about how I learn and reminded me that growth takes time, work, and patience.
From the blog Site Title by Roland Nimako and used with permission of the author. All other rights reserved by the author.
Hola!!
The name’s Jancarlos Ferreira, current third year student at Worcester State University, studying Computer Science and Business Administration as a minor. Coming into this field, I under-estimated the size of it and the variety of opportunities and educational aspects. This blog will serve as a forum to speak on topics that pique my interest in terms of it and software specifically. The near future is unrecognizable, yet limitless. And I plan on taking advantage of every opportunity that I am deserving of.
From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.
Introductory Post
Hi, this is my new blog for software quality assurance and testing.
From the blog CS@Worcester – CS Journal by Alivia Glynn and used with permission of the author. All other rights reserved by the author.
Introductory Post for CS 443
My name is Santiago Donadio and I am currently enrolled in CS 443 Software Quality, Assurance, and Testing. This class will be a great compliment to the other computer science courses I am currently taking; excited to get back to blogging!
From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.
Intro to CS-443
Hello, this is my blog for all things related to Computer Science, including CS-443 Software Quality Assurance & Testing. I hope this semester and class goes well for everyone! Have a good one.
From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.
From UML to Design Patterns: Refactoring the Duck Simulator
Hello everyone, welcome back to my blog! In my previous post, I explored object-oriented design basics and the importance of UML diagrams for understanding class relationships. This week, I applied that knowledge to a practical assignment by refactoring the Duck Simulator project using several design patterns, and I want to share what I learned from the process.
Introduction
UML diagrams provide a visual blueprint for software systems, helping developers understand relationships, dependencies, and responsibilities of different classes. While useful on their own, combining UML with design patterns allows us to translate those visual models into flexible, reusable, and maintainable code. In the Duck Simulator project, I used UML to identify repetitive behavior and then applied Strategy, Singleton, and Factory patterns to improve the system’s design.
Using UML to Identify Problems
Originally, the Duck Simulator consisted of an abstract Duck class and subclasses like MallardDuck, RedHeadDuck, RubberDuck, and DecoyDuck. Each duck implemented its own fly and quack methods. My UML class diagram made it clear that this design was repetitive: multiple subclasses had similar or identical behaviors. This repetition violates the DRY (Don’t Repeat Yourself) principle and makes the system harder to maintain or extend. The diagrams highlighted the exact areas where behavior abstraction could be applied, providing a clear roadmap for refactoring.
Applying the Strategy Pattern
The first refactor I implemented was the Strategy Pattern, which separates the fly and quack behaviors into FlyBehavior and QuackBehavior interfaces. Each duck is assigned a behavior object rather than hard-coding methods. Using UML, I could visualize how Duck classes now depend on behavior interfaces, not concrete implementations. For example, RubberDuck now uses the Squeak behavior, and DecoyDuck uses MuteQuack. This change made it easy to swap behaviors dynamically and reduced duplicated code across subclasses.
Using the Singleton Pattern
Next, I noticed that all ducks shared identical behaviors like FlyWithWings and Quack. To avoid creating multiple unnecessary instances, I applied the Singleton Pattern. UML helped illustrate that each behavior class has a static instance and a getInstance() method. This ensured that ducks reused the same behavior object, saving memory and improving consistency.
Implementing the Simple Factory Pattern
Finally, I created a DuckFactory to centralize the creation of ducks with their associated behaviors. UML shows a clear dependency from the simulator to the factory, encapsulating construction logic and removing manual behavior assignments in the simulator. This simplified code maintenance and improved readability, while maintaining all Strategy and Singleton benefits.
Reflection
This assignment reinforced how UML and design patterns complement each other. The diagrams helped me see problems in the design, and patterns provided proven solutions. After completing the refactor, the Duck Simulator is now modular, maintainable, and extensible. I can confidently add new duck types or behaviors without touching existing code. Personally, I learned that UML isn’t just documentation, it’s a tool that guides better design and code structure.
Resources
While exploring this assignment, I also reviewed a great resource that breaks down the concepts from Head First Design Patterns in a clear and structured way. You can find it here on GitHub. It helped me connect UML representations with real-world code implementations, especially when applying the Strategy Pattern in my Duck Simulator project.
From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.
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.
Welcome
I’m glad you could join.
From the blog CS@Worcester – Learning coding by kings lead and used with permission of the author. All other rights reserved by the author.
My First Blog
This blog will be my running log for CS-443. I’ll post notes from class, including assignments and outside resources, as well as discussions we have in class.
To start, this class has an interesting grading system, with 3 points given for an assignment, 3 if it perfectly meets specification, down to 0, if it’s not submitted, with reflections on assignments for 1 or 2 points possibly increasing said assignments grades by 1 point. From discussions in class, this seems to be an attempt at better documenting students abilities in certain fields, as getting an overall C in a subject doesn’t really give you a good view on what specific topics they did well on, or what they did terribly on. I’m interested to find out what’s next.
From the blog CS@Worcester – Learning coding by kings lead and used with permission of the author. All other rights reserved by the author.