Recently in my Software Construction, Design and Architecture class, we have been getting into UML class diagrams. The class diagrams provide an understandable system structure and the relationships among the objects. Each relationship has a distinct visual representation based on arrows:

In this case, we started using Visual Studio Code and PlantUML to model class diagrams. I referred to the UML documentation that was provided to get a better understanding of how to display each type of arrow in PlantUML.

As shown above, there are three kinds of relationships that can be represented in PlantUML: Extension, Composition, and Aggregation. I am not totally familiar with the use of composition and aggregation as we’ve only been focusing on models that use extends and implements in class. I wanted to get a better understanding on how to read UML class diagrams and to be able to tell the relationships between the objects on the diagram.

With PlantUML and Markdown preview in Visual Studio Code, you can see changes to the UML diagram in real time as you modify the code. What you write in the code will reflect what shows on the diagram. You can also manually draw the relationship, which provides more customization such as arrow length, direction, etc. In addition to solid lines, you can use dotted lines to represent dependencies.

Extends is represented on a UML diagram as a solid line with an empty arrow. By writing that Class A extends Class B, you will see the diagram update show a line with an empty arrow point from Class A to Class B. Instead, you can also write Class A <|– Class B in order to display it on the diagram. When viewing the diagram alone, you can assume that Class A has access to all attributes and operations available in Class B.

Implements is represented on a UML diagram as a variation of the extension arrow, with a dotted line instead. By writing that Class A implements Interface, the diagram will be updated to show a dotted line with an empty arrow pointing from Class A to Interface. To draw an inheritance arrow on the diagram, you can write Class A <|.. Interface. When taking a look at the diagram, you can assume that Class A has access to the operations of Interface and contains the code for them.

I found the PlantUML documentation very useful as it contains basically everything you need to know about using PlantUML to create class diagrams. I also really enjoyed the functionality to modify the example diagrams to experiment with the features that you just read up on. Overall, I think that UML class diagrams are a good way to visualize a class structure. The arrows are easy to follow and help in understanding the relationship between classes.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

For in-class activities of this week, we learned about modeling with UML class diagram. There were many important elements to compose a class, such as properties, operations, and association. However, my team got stuck at the “association” section, we could not clearly distinguish the different types of relationships between two classes, especially the relationship named have-a. Therefore, I thought it was a good opportunity for myself to learn more about the term “association”.

There are many articles and blogs analyzing about different types of relationships between classes. However, many of them look very complicated with a long list of different relationship types and some are very confusing. Fortunately, I found this article, entitled Association, Composition and Aggregation in Java, which finally satisfied my curiosity about “association”, because the content of this article is focused only into the definition of “association” and the analysis of its types which are aggregation and composition.

There are some key points that I have taken away after reading the article. First, association represents a relationship between two classes, depending on each situation, association can be one-to-one, one-to-many, many-to-one, and many-to-many. Second, association has two special forms, which are aggregation and composition.

For aggregation, this term is also known as has-a relationship (a weak association), which is one way relationship and each entity of the relationship can exist independently. The author also provides a simple example to describe those characteristics of aggregation, which is an Institute has-a Department, and Department has-a Student. This is one way relationship because a department can have students, but vice versa is impossible. Moreover, if the Department class is removed, the Student class can still exist independently.

For composition, this is the part-of relationship (a strong association), and the two entities are dependent to each other, which means a class (child) cannot exist without the existing of another class (parent). For this definition, the author gives an example of Book and Library, Book is part-of Library. So, if Library class is removed, Book class cannot exist. In my opinion, this example does not make sense to the part-of relationship because I think Book still can exist without Library. Therefore, I have looked for other resources to find a good example for composition. UML Association vs Aggregation vs Composition is a good resource to provide real-life examples for each conception. Like the first article, this one also focuses on the analysis of the term “association” and its two special types, aggregation and composition. According to the article, I got an example that Head, Hand, Leg are part-of Person. Thus, if Person class is removed, Head, Hand and Leg classes cannot exist. For myself, this is a perfect example to describe the term composition.

In short, I have learned a lot of information and had a clear understanding about the term “association” from the two articles recommended above. I will apply this knowledge to design relationships between classes in my UML diagrams. Moreover, I believe the articles that I choose are good resources because their content is clearly organized with good examples. In other words, I would say the two articles complement each other, so it is good if readers can pull out the best parts from each article and be able to combine them consistently.

From the blog CS@Worcester – T&#039;s CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

As my journey to find my very first internship as a software developer. I’ve noticed that the majority of the posts require Docker’s experience. From there, I realized that Docker is an essential tool for Software Developers and their professional careers. This blog is about Docker of what it is and also why it is necessary nowadays.

Docker is a container running time. A container is a standard unit of software that packs up codes and all their dependencies so the applicant might run quickly and reliably from one computing environment to another. Docker container is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings

The good thing about Docker is it helps developers get their application to work on every machine. Also, the abundant app’s libraries and dependencies ready to be executed make Docker even better compares to its same category competitive. Besides that, Docker is lightfast and also very easy to maintain.

Also, running applications in a container brings many benefits to both developers such as:

• Portability: Once developers run their containerized application on their machines they also would be able to deploy it to other operations and be assured that their applications would perform the same as on their own.
• Performance: VMs are alternative methods for developers but Docker offers much more compared to regular VMs as faster to deploy, quicker to start, and smaller footprint than ordinary VMs
• Agility: Containers offer portability and performance help reducing time-consuming and make the process responsive and agile. Such advantages provide a better way to deliver the right software at the right time.
• Isolation: A Docker container that contains one of the applications also includes the relevant versions of any supporting software that the developer’s application requires. If other Docker containers have different versions of the same supporting software, that is not a problem because Docker containers are independent.

Most uses of Docker make developer life simply better while developing applications. But it does not mean that Docker could entirely replace the actual Virtual Machine. VMs are still much needed if we have to have a whole operating system for each customer or the entire sandbox. VMs are still being used as middle layers when you have a big server framework and many customers that using them. Despite many good things that Docker could bring to developers, VMs still has a firm grip within the industry and development cycle.

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

Today, I will be talking about an article titled, “MongoDB : an Introduction” by Harshit Gupta on Geeks-for-Geeks.com. This article explains what MongoDB is in a simple format by comparing it to relational databases. He explains that MongoDB is a NoSQL database meaning it is non-relational. Instead of storing data in a tabular format such as SQL, it stores data in its document model which is much more flexible. This makes it similar to a JSON format (called BSON which stands for Binary JSON). When dealing with big data, it is a much better choice to use MongoDB instead of a relational database because it is horizontally flexible. This means that if the demands of the database grows, we can add more servers so that it can handle the change. While adding a new column to a RDBMS requires replanning of the schema, adding new fields to a NoSQL database is easy because it is schema-less. Another major feature is that MongoDB is a distributed database meaning multiple copies of data is stored across multiple servers making data recovery fast and reliable. The article provides easy to read bullet points on the features of MongoDB, when to use it, and also the differences between MongoDB and RDBMS. It also goes over the languages it supports, how to install it, and provides a list of major companies using it.
The reason I selected this source is because Geeks-for-Geeks has always been a trusted website that I will go to when having problems in programming or with topics in class. They always provide a well thought out, simple explanation for topics that seem confusing in a textbook. While reviews for Geeks-for-Geeks are mixed, it has always been reliable for me and I have never had any problems with it. For basic topics at least, it has been very accurate. The content in this article held up with everything I have learned about MongoDB already, and also, matched up with what other writers said about it.
I chose this topic/article because I thought it would be good for anyone in class who does not yet know what MongoDB is and would like to read up on it. In this course, we will be using MongoDB for our final project to store data so we will be using it in the future. I started learning about MongoDB with this article as a good introduction then took it to more concrete and informative websites to learn about it further. MongoDB is good to learn if you will handling large amounts of data in the future.

Source: https://www.geeksforgeeks.org/mongodb-an-introduction/

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 this week’s post for my blog about the crazy journey of coding, I will be talking about the SOLID principles. The reason I am selecting this topic is because it sets the tone on how to produce quality code. Many times, especially for most students like me, we rush to finish up any coding project we have and don’t live up to the potential that could have been put forth. Therefore, SOLID principle help give a guideline to follow for almost any programmer to outcome the best work.

Well S.O.L.I.D is actually an acronym that stand for five important principle of object-oriented programming by Robert C. Martin, who is commonly known by as Uncle Bob. Now if you have read my first blog you would know that I went to a lot more details on object-oriented programming and I would suggest everyone read up on that before reading this post. The essential purpose of the principles to create software that is easy to maintain and add onto in the future. These principles also help detect any minor problem in the code that could lead to bigger problems and help change around code any time on the code journey. Now let’s get into what these letters actually represent.

The S in the S.O.L.I.D principle stands for Single Responsibility Principle and it states that a class should have one and only one reason to change, essentially meaning a class should only have on job. This concept should be fairly easy to understand as one class should be responsible only for what it represents and all the methods in the class should correspond to that. The second acronym O stands for Open-Closed Principle and it states that objects or software entities should be opened for extension, but closed for modification. What this essentially means is that classes should be able to extend its behavior, but not be modified. This can be done in various different ways such as through inheritance or an interface, but the main guideline is not to modify.

The L in the S.O.L.I.D principle stands for Liskov Substitution Principle and it states that objects of a superclass can be replaced with objects of its subclasses without breaking the software application. What this simplifies too is that the objects of the subclass need to behave in the same way as objects of the superclass. The next acronym I stands for the Interface Segregation Principle and it states that no client should be forced to implement an interface that it doesn’t use or clients shouldn’t depend on methods they don’t use. These interfaces are difficult to maintain and change over time so it is best to avoid. The last acronym in the S.O.L.I.D principles stands for Dependency Inversion Principle and it states that software entities must depend on abstractions not on concretions. This is due to the fact that abstractions change less and so make it easier to change behavior.

I think personally these principles are all key to establishing good solid code. In the future, I expect myself to catch myself when I am coding and follow these principles. With this outlook, I will be able to keep a clear focus from start to finish of a project, and won’t compromise one thing for another. The principles create a clear road to follow and I have benefitted from learning about it.

To read more up on the S.O.L.I.D principles, here are some sources to check out which I have used for research:

View at Medium.com

https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

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.

As a student learning new things every day, I chose this topic because I was curious as to what it really entails in computer science as it is one of the topics that directly relates to the course. However, little did I know that it was an abbreviation for 5 important design principles employed in software programming to make software designs more understandable, flexible, and maintainable.  I selected this blog because it explains briefly but detailed about each principle of SOLID and definitions.

This blog talks about who introduced the acronym SOLID and its importance. Also, what it stands for, which are Single-Responsibility, Open-Closed, Liskov Substitution, Interface-Segregation and Dependency-Inversion Principles. Not only does it explain each principle, but explanations are concise and easy to comprehend. It has some links that provides detailed explanations to some of the principles, giving examples that enables one to grasp the concept fully. It also explains why each concept can help developers to build better software and the importance of cohesion and less coupling in software development.

In this blog not only did I learn about the 5 principles, but also learned that it is a part of object-oriented programming that enables one to write a better code that is robust. I learned in Single-Responsibility Principle that classes should have a unique responsibility and that will help reduce complexities, reduce dependency on other classes, ensure readability all in while leading to a stronger cohesion. I believe that the quote “do one thing and do it well” has come into importance in this principle as that will help me avoid fusing too much responsibility on classes in my future programs to make editing of codes easy.

In Open-Closed Principle, I learned that any class written or coded can be used as it is written. It can be extended but can not be modified. However this principle made me understand more about inheritance and polymorphism in the sense that classes can be open if attributes can be added but closed if it is available for use/extended/implemented by other classes. I always used to be a victim of modifying parent classes if there are any errors in my sub classes which should not be the case. Also, this principle improves readability.

When looking at sample programs using interfaces, I never understood why interfaces could not be segregated into one, rather such programs could have more than one interfaces. Also, one class could implement many interfaces. However, this blog made me understand why this is the case in Interface-Segregation Principle that an interface can be broken down into smaller interfaces that are specific rather than making it large. In addition, classes do not need to implement interfaces they do not use.

I will encourage other students to read this blog as it helps understand more concepts in Object-Oriented Programming to make them better programmers.

https://apiumhub.com/tech-blog-barcelona/solid-principles/

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