Category Archives: Week 1

The Usefulness of UML

This week, we have started talking about UML (or Unified Modeling Language) in class, and while I can see some of the usefulness of UML, I wanted to see how people actually use it in the context of a workplace environment. So as a part of this, I found a blog post by Lucidchart talking about different types of UML diagrams. While this blog post is made by a company, and they are trying to get the reader to use their product, I don’t think detracts from the usefulness of the post.

So in this blog post they talk about how Agile developers can incorporate UML into their development process, as well as 7 different types of UML diagrams and how each one is useful, and which context it is useful for. It is largely just an overview of these different models, and I know there are more types of UML diagrams, but this gives a fairly good breakdown of what UML is and how it can be used in a more real-world context. I chose this post as I personally found it useful in understanding why anyone would actually want to use UML outside of a planning stage, since you are essentially planning out the whole class structure before you design it, so in my mind why wouldn’t you just write the code? Well this post makes the case that UML makes very good documentation for your code. If you have a class diagram, like the kind we worked with in class, you can use that as a sort of blueprint for your code. So you don’t have to scroll through hundreds of lines of code just to find all of the methods that are in it and how they interact with other classes, you can just look at the UML diagram. They also make the case that UML can be a valuable tool in explaining code to others.

From this blog post, I think I have a better understanding of how UML is (and should be) used in a workplace. There are a lot of different types of diagrams that were shown that I didn’t know were part of the point of UML, as I have only ever seen the class diagrams. But there are many models that fit under the purview of UML, each with different use cases. Some model runtime behavior in a way that it could be easily explained to someone who has no knowledge of programming, and some are able to show how different methods or classes communicate with one another, creating a diagram that can be easily looked at to make sure you aren’t going to mess with interactions in a system by making certain changes. I think that, given the proper context, UML could make a much more significant impact in understanding how we code, and has the ability to explain code to others in a way that even more traditional documentation methods lack.


From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.


My name is Hung P Nguyen, I’m a senior at Worcester State University and majoring in Computer Science with both concentrations in Software Development and Big Data. The focus of this blog would be on the knowledge that I would gain while attending CS-343. Other than that, this blog would also be about me learning new techniques outside of the classroom and being able to adapt to technology. Personally, the most interesting thing that brings out my curiosity is Docker. As a necessity to many developers, Docker is playing such an essential role in their work-life which question me about its existence and practice

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

JUnit 5

This week we had our first assignment. This assignment was about practicing writing JUnit 5 test cases. I am familiar with Junit 5 test cases from another computer class in last semester. Because I haven’t used Junit or coding in java for a while it took me a while to remember what I knew and how to code the test cases. JUnit 5 is most widely used testing framework for java applications. For very long time, JUnit has been doing its job perfectly. In between, JDK 8 brought very exciting features in java and most notably lambda expressions. JUnit 5 aims to adapt java 8 style of coding and several other features as well, that’s why java 8 is required to create and execute tests in JUnit 5.

In this homework, we had a BankAccount class and create at least one test class for the Bank Account System using Junit 5. In the base assignment we had to write the test for the methods that were in the BankAccount class and at the same time create a private method. In the intermediate we had to the write tests for which may include Custom Exceptions. In JUnit 5, to test methods which throws exceptions, we should use .assertThrows() method from org.junit.jupiter.api.Assertions class. The assertThrows() method asserts that execution of the supplied executable block or lambda expression which throws an exception of the expectedType.

In the advance I had to watch a podcast from Sam Brannen, Deep Dive into Junit5. The podcast was very interesting. From here I learned the fun fact that Junit5 is called Jupiter, the reason is Jupiter happens to be the fifth planet from the Sun. He explained some advantages and differences that Junit 5 has over 4 like; JUnit 5 has new features for describing, organizing, and executing tests, especially the display names and can be organized hierarchically, Junit 5 can use more than one extension at a time, you can easily combine the spring extensions with other extensions etc.

Overall, I really enjoyed working in this assignment even though I had to refresh my skills in java and writing test cases has always been a challenge for me but that doesn’t mean that I will give up.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

I want to start this blog with something very interesting that I read in the book; Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow. Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you will not realize that you may not be learning as much as you think. It is interesting and true but also, we have to be careful because there are risks. You can end up feeling bad about yourself and your skills or there is more than you can handle so is good and bad being in strong group.

This semester I’m learning something new in software development capstone. This means that I have to read new information and trying to understand it. Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. This book help explains that you must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it. I feel this chapter is so relevant to me because sometimes I feel lost with all that reading and new information. While Expanding Your Bandwidth can be fun and is an interesting skill in and of itself, for the apprentice it is a means to an end.

I always try to hide my ignorance when I don’t know something about a topic. This book helped me understand that it fine to not know or understand it. It helped me to work with my problems and allow yourself to Expose Your Ignorance in a specific technology in order to focus your attention on what you need to learn next. Then Confront Your Ignorance and let your team and your customers watch you flex your knowledge-acquisition muscles. When all this new information and mind-stretching becomes overwhelming, it’s important to Retreat into Competence, remember how far you’ve come and the skills you’ve developed, and gather yourself to ascend to the next plateau.

Source: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, Chapter 1 and Chapter 2- 6 Introduction.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming

This blog post is going to be about one of the most important concepts in today’s world of computer science and it is object oriented programming. The reason I chose this topic is because it directly relates to course material and is fundamental for most computer science students.

I’m going to first start of by explaining the basics of objected oriented programming and try to bring some clarity to people who are either new to coding, or want to learn about a different mechanism of coding. Now keep in mind, there are many different ways to code and different approaches one can take on his specific journey. Now to the outside world of coding, they might think it’s all the same. However, specific types of ways to code include objected oriented programming, functional programming, procedural programming, logical programming, etc. I will expand on this later when I talk about my real life experience with some different ways.

Essentially, object oriented programming consists of object which are created by variables and methods. It consists of many objects who are collected and arranged in a specific class for unique uses based on the person’s needs and end goal. The four main concepts of object oriented programming include encapsulation, abstraction, inheritance and polymorphism. Encapsulation is choosing to limit certain object’s information to be seen by everyone in a way to protect information. Usually this is done by using a private access modifier. Abstraction is similar to encapsulation, except it hides properties from everyone in order to make the outside code a lot more simpler and understandable. Not everyone needs to know the broad details behind the object and helps keep things from causing problems on the main front. Inheritance is when a subclass basically inherits its properties and methods from the parent class. The main objective of this is to reduce redundant code and make things easier to use. Polymorphism is when an object can have multiple functions and change methods through the process of overriding and overloading.

Now the most popular programming languages today are objected oriented programming such as Java, Python, C++, etc. Now two languages that I have had experience with was Java and C programming. Java is an object oriented programming language, whereas C is a functional programming language. When I was learning Java, I never understood the big deal with Java and object oriented until I learned C and saw how not as much could be done. Java is much better equipped for real world projects as it makes code very reusable, simpler as well as saving memory. With C functional programming, there was more code to write for accomplishing simple tasks and also there was less security with direct access to memory. Overall, going into the future I am going to improve my java skills and be more equipped with the simple as well advanced concepts of objected oriented programming because of the many types of projects that can be created with it.

To read more info on object oriented programming link which I used as a reference here is one:,basics%20of%20a%20computer%20program.

To read more info on different ways to program this is a another link with helpful information:

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Integration Segregation Principle

This blog is about the Integration Segregation Principle (ISP) based off of the “SOLID: Integration Principle” article by Anu Viswan. This topic relates to the course (CS343) because we will cover SOLID, a combination of principles which contains ISP.
Integration Segregation Principle is about organizing your interfaces in a way where you will not be implementing methods that are not needed in your subclasses. The example given in the article by Viswan contains an IPrinter interface with an All-In-One Printer class and an Economical Printer class. The example that shows bad technique in ISP displays the IPrinter interface with three methods: print(), scan(), and copy(). For the All-In-One Printer class this is fine since as it has the functionality of all three methods. However, the Economical Printer class only prints. This leaves us putting exceptions in the scan() and copy() methods. This could lead to a violation of the Liskov Substitution Principle and is also known as a “fat interface” or “interface bloat”.
This problem is most noticeable when each of the implementations have separate assemblies. When making a change in the interface, all of the assemblies have to be rebuilt even if it seems as there is no change in their functionality. ISP reduces the impact when making changes.
The example of the correct way to build the IPrinter interface as given by Viswan would be to create smaller interfaces with an IPrinter interface containing the print() method, an ICanScan interface containing the scan() method, and an ICanCopy interface containing the copy() method. Now, the Economic Printer class can implement only the IPrinter class with the methods it supports. Meanwhile, the All-In-One Printer class can implement each of the new interfaces giving it all the additional features.
One side note about this example that Viswan added to the end that I found important to clarify is that this does not mean that all interfaces should have only one method but that we should understand the responsibilities of the interface.
I chose this topic because I think it is an essential rule to follow in order to have a solid and well-rounded class hierarchy that will not cause problems down the road. I chose Viswans article in particular because the content by Viswan on the rest of the SOLID principles seem very reliable, accurate, and well thought out. This will be of great importance when designing our final projects for this course.


From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.


In my first programming course, I asked my professor how important it is that I learn Object Oriented Programming (OOP). He replied by saying, if I want to program anything, I must learn OOP. Being a freshman then, I took that lightly until I started coding and did not understand what I was doing. It was then that I realized how important it is to learn about OOP and utilize the concept in my program. As students especially beginners in programming, we are so geared towards completing programming assignments, projects etc that we fail to really understand what is used to structure a software program which OOP is basically about.

I selected this specific blog post because it talks about OOP and what it entails. The blog explains OOP as a programming paradigm that relies on the concept of classes and objects. It provides the importance and reason for OOP. It also explains classes, objects, methods, attributes and provided some examples, code snippets and OOP structure. I believe that this is important to know especially for new programmers, to better understand, and help structure their programs as well as others. The blog also explains the principles of OOP which is inheritance, polymorphism, abstraction and encapsulation. It provides code snippets of how each of these principles are seen and employed in codes and programs. It also provides a table that summarizes each concept.

In this blog I learned more on inheritance that it supports reusability. I learned from previous programming class that subclass can inherit all attributes of its parents class and add more attributes but little did I know that subclasses do not have to redefine methods that are already defined in parent class. When a method is called, it goes up to the child parent classes to find where that method was defined. It used to be a common mistake in my programs as I would redefine methods from parent class in subclasses and I never clearly understood why I got errors.

Also, I learned on encapsulation that, it hides the internal software code implementation inside a class, and hides internal data of inside objects. After reading this, I am sure to employ this method to hide information that I would not want to change in my program or code. In the past, I wasn’t able to understand the difference between protected and public codes when I see them, other resources made it very ambiguous for me to understand. However, thus blog provided a simple, easy to understand difference between them. Public codes are those that can be accessed by other classes in the program and protected are those that can only be accessible to subclasses.

I hope beginner programmers will find this blog helpful. For continuous programmers, this blog will help broaden your understanding and knowledge of OOP like it did to me.

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

Object Oriented Programming

I would like to start my blog with a concept that is known for all computer scientists around the world. OOP or the long-term Object-Oriented Programming.  The OOP has been around since 1980, but unlike trendy fashions and video game characters, this programming model is still going strong after these many years.

When I was first introduced to OOP, I felt like I was never going to learn it. But like wise people say, practice makes you perfect. Most of the courses in colleges requires a good understanding of the OOP. In the CS-343 course we have to perform object-­oriented design and programming with a high level of proficiency so OOP will be a key in our projects that we are going to develop. You cannot develop software for mobile unless you understand the object-oriented approach. The same goes for serious web development, given the popularity of OOP languages like Python, PHP and Ruby.

You have decided to learn object-oriented programming, but you don’t know where to start. Object-oriented programming has so many concepts and features. The whole thing can feel overwhelming at times. It is easy to make mistakes when you construct a program using OOP. So, what to do When everything goes to hell? Duplicate and rethink.

Abstractions are tricky. When used properly, they can help you maintain your code over time. However, a wrong abstraction can add a lot of unnecessary complexity to the project and trap you in an even worse maintenance hell.

So how to avoid the wrong abstraction? How to recognize when an existing abstraction isn’t right for us anymore? And what can we do about it at this point?

When I made that mistake and I was looking for any information how to fix it, I found a good blog that gives you good directions on what to do next. Object Oriented programming requires thinking about the structure of the program and planning at the beginning of coding. Looking at how to break up the requirements into simple, reusable classes that can be used to blueprint instances of objects. Overall, implementing OOP allows for better data structures and reusability, saving time in the long run.

I have attached the link for you to read and have a better understanding. It is easy to get lost in coding, but the important part is that you still can get out of it. I hope this blog helps a little with your programming problems and make your life easier.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

A little less salt.

When using principles or techniques in code, we need to use them in moderation and understand the meaning behind them; otherwise we over-salt our code. The post that I will use in discussion explains a common salting problem in programming, the article was found in an early programming blogpost from Coding Horror, to reflect a topic that is relevant in programming and also discussed in one of my courses. The topic is Object Oriented Design.

In the article that I chose, titled, “Your Code: OOP or POO?”, the author, Jeff Atwood, talks about how many programmers these days are not using Object Oriented Programming correctly. He attributes this problem to institutions that rush and advise the usage of OOP to their students without properly explaining when and why objects are necessary in programming design. In addition, he also blames the pro-object culture that is common among programming communities, where programmers glorify objects and boast the superiority of object oriented languages over non-object languages. Due to these influence, he explains that it causes programmers to undergo object happiness, a frenzy of object-izing everything in their code. This mess, is the coding horror that is seen when Object Oriented Design is used improperly.

To address these concerns, Atwood recommends POO, Programming fOr Others, which brings in the element of empathy into programming design. What Atwood proposes is that programmers should be thinking about their audience, such as their readers, who will have to make sense and use their code. So, along with implementing other OOP principles, such as, encapsulation, simplicity, re-use and maintainability; Atwood encourages empathy and to build code while keeping in mind what their readers would want or need and to anticipate what they need to do next when following the code. Atwood concludes his argument with ‘programming as if people mattered will always be a more effective strategy than satisfying the architecture astronauts’.

Although this is an early post, which was posted on 2007, the topic of this post still holds relevance. While continuing my CS undergrad studies at WSU, I have noticed this pro-object culture, where object oriented languages are remarked as superior than non-object languages and I have also noticed that some of my peers falling victim to object happiness and not having a firm grasp of OOP principles. I also feel that this post was a good reminder, that we should be questioning our studies and what we are taught at institutions in programming. In a sense, it was a good step back for me to reevaluate my principles and goals in coding. It also brought in a new perspective, the element of empathy; where one should code as if people mattered; rather than solely focusing on the efficiency of the solution; we should also consider readability and simplicity of our code.

The link of the source can be found here

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

Test Driven Development

As I progress more in my CS studies, I’m starting to move beyond learning how to write the code for a project to how the project should be designed overall. In fact, this is one of the main purposes of two of my current CS classes. This has lead me to learning about TDD, or Test Driven Development. I’ve come across a fantastic article by Andrea Koutifaris which outlines the concept well called Test Driven Development: what it is, and what it is not.

In this article, I’ve learned the purpose of writing test driven code and what the plan for doing it should be. In TDD, tests come first in the process while writing production code comes second. This is in order to almost put oneself in a user’s shoes. If I myself in the user, what do I want my code to do? This is where the tests come in. Once the goals are clear and defined, the production code can be written.

The rules for TDD can be broken down to two essential parts:

  • “Write only enough of a unit test to fail”
  • “Write only enough production code to make the failing unit test pass”

Tests must be written to be very specific and achieve the ultimate application goals. Analysis of your tests can help you determine a method to writing your production code. They often not only outline what need to be achieved, but how it needs to be achieved.

The next part of TDD would be writing production code. As outlined before, the second essential rule of TDD is to “Write only enough production code to make the failing test unit pass.” Had production code been written first, output may not match user goals and unnecessary code may be written, which comes with its own set of problems. The focus is on writing clean code and limiting the amount which you write.

The last part of TDD would be the “refractor phase.” This is where code can be changed to be better, but what is stressed here is removing all duplicate code and consolidating.

The result of TDD should be efficient, clean code which serves its purpose. Although it can seem long-winded and like extra work, it’s mostly just inverting the process which we usually work by, so once the process is learned and practiced, it can help with writing better code more coherently and more focused on user goals, which is the ultimate goal as a programmer.

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