Over the course of several weeks, we’ve been working with a modeling language called Unified Modeling Language (UML). UML is a visual language that visualizes the structure of a program using UML Diagrams so that its behavior can be analyzed by developers. Different objects and classes, such as a class hierarchy or object composition between classes can be easily represented¹. By visualizing the software’s code, the UML Diagrams allow a far quicker way for a developer to analyze its behavior and if necessary, allow refactoring in the code.

Code that is poorly designed can contain what is called Technical Debt. Technical Debt of poor design implements at least one of the seven Design Smells; Rigidity, Fragility, Immobility, Viscosity, Needless Complexity, Needless Repetition, and Opacity². Code that is difficult to change has the “smell” of Rigidity, and must be refactored in order to allow change and flexibility in design. 

In class and in homework, we’ve been given code and a UML diagram providing the structure of said code. Using the UML Diagrams, we can understand where the code is going wrong, and what to do to refactor the code to remove its Design Smells. Without the UML Diagrams, we’d only have one or two objects or classes at a time to look through, making its structure far more difficult than it would otherwise be without using them.

On the other side of development, creating software while implementing a UML Diagram is very easy to implement, even for a university student. This ease of implementation and its low cost has allowed UML to become a standard through the International Organization for Standardization (ISO)¹. As such, there does not exist a good reason why a developer would not want to document his implementation using a UML Diagram.

I wanted to discuss UML Diagrams and the Design Smells because I’ve developed software consisting of over 10,000 lines, and it is very easy to establish a confusing nexus of classes and objects. It is also very easy to lose track of the design, or hard to understand the system’s design without something like a UML Diagram. The Diagrams we’ve discussed in class and gone through in the homework is another big reason, as I understood the logic of the code and what needed to be done before I even saw a line of code. I will be using UML Diagrams from now on so I may be able to document my code for myself, maybe even for the students I help tutor that need help understanding class hierarchies.

Links:

1. https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

(Provided a good explanation of UML)

2. https://learnbycode.wordpress.com/2015/08/01/401/

(Good explanation of the Design Smells)

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

“Don’t ever leave your baby in the road.” – My First Computer Science Professor, 2015.

That came out of left field, didn’t it? However, the quote (much like YAGNI) makes a lot of sense in the world of Computer Science. Specifically, this quote refers to the idea that you should never “assume that you’ll always be careful and pay attention”, but rather you should prevent any mishaps from happening in the first place. Global variables, for the most part, should be avoided; the ability to be accessible from anywhere within the program is dangerous to say the least.

However, the “Singleton” method of refactoring seems to make an argument for the usage of global variables (provided that they still have a level of protection from modifying the data). Singleton refactoring works on the idea that having one “global” instance of a behavior class can save on memory; client classes using the same behavior can reference that single class. However, due to certain features (for example, making the constructor a private method within the class), having a global Singleton object will not endure the same problems that traditional global variables bring to the table.

This is opposed to the “Strategy” method, which involves creating new classes upon new classes for each new behavior found within a project. This way, we can create an interface for this behavior, and have it implemented by client classes that use it (this will save on memory from unused, inherited methods). Yes, the Strategy method is a step-up from mere method overriding. However, its need to constantly create new classes takes up massive mountains of memory in its own right (which can lead to poor performance).

Both ideas (the Singleton and the Strategy) are discussed within the articles linked below. I personally picked these articles due to the fact that they were my “help reference” when working on some of the homework assignments. Refactoring Guru is a great website that summarizes different refactoring strategies, as well as providing pseudocode and applications of each strategy in the real world.

I hope to use this newfound knowledge to improve upon my refactoring skills; this in turn will cut down on code smells, and create more efficient solutions to programming problems. When considering the Singleton design, we can use global variables without running into code smells such as “needless complexity” (by bringing in an unnecessary aspect), “viscosity” (by making future updates more difficult to implement), or “fragility” (by errors caused from having the data modified anywhere within the program). As for the Strategy design, we can ensure that classes only contain methods that they’ll actually use; this cuts down on the “needless repetition” coding smell (by ensuring that inherited methods don’t go unused).

Links: https://refactoring.guru/design-patterns/strategy

https://refactoring.guru/design-patterns/singleton

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I’ve decided to continue watching the video I started in my last professional development post, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams. Again, since I will likely be making more UML diagrams in my educational/professional life, I want to further develop this skill. In my last post, I learned how to create a Use Case Description, and in this post, I will discuss how to use a Use Case Description to create an Object Model and a Sequence Diagram.

Derek starts his Object Model by using the actors he listed in his Case Description to create 3 separate object boxes in his Object Model diagram. He connects the actors/boxes with a line to show what action is carried between the given object and the multiplicity that each box has. Next, Derek fills in each object he has created with pertinent data fields, for example, since there is one object box for two players, he adds name as an important piece of information to differentiate the two players. This process was valuable to me because I tried to predict what information would be important before Derek did. I wanted to include some methods in the object model, but I learned this is not where I do this. Derek only includes attributes of the objects and other objects that a specific class will use (e.g. the CoinGame includes both the players and the coin actors).

The next thing Derek does is create a Sequence Diagram. It is important to mention that in this video, Derek mentions that he has another introductory video into Sequence Diagrams so he goes somewhat quickly through this process. Either way, there was a lot that happened and that I learned from observing this process. Overall, the main takeaway from this part of the tutorial is that Derek uses the Steps of Execution from the Case Description to lay out the logic of the program he is creating. Throughout this process I thought it was interesting that there were some things that Derek, himself, was not sure of as far as what made the most logical sense, but he went forward with what worked for him. This was really insightful because as I practice this process on my own, I’m realizing that I can create a similar program with a slightly different logical order of what makes the most sense to me.

My goal is to continue following Derek along in this process so I can use a similar approach to create a simple program on my own. For my next post, I’m considering following Derek as he creates a UML he describes to be “easy” now that he has his Sequence Diagram created.

Tutorial link: https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

After working with docker in the past couple activities, I wanted to learn more about docker, particularly how docker uses images and containers after working with them in activity 6. I have a good idea on how they work and some differences between them, but I wanted to look more into images and containers to have a better idea and clear up some questions I had from the activity. The post that I read that talked about these two elements relating to docker and was helpful to me was “Docker Image vs Container: What is the difference?” from phoenixNAP.

Docker images are the executable files that have the source data for the containers to run, and the containers run by the images. Containers are environments in docker where users can interact with applications. Containers need images to run, and without a container to run, images aren’t very useful. Images cannot be edited because they are almost always in read-only mode, and can act as a preview to the container.

What I did not know about images was how an image can have multiple layers, with one of those layers being the base for the container. Unlike containers, they can not be stopped or run.

I knew that containers were the main places where you can interact with the program and incorporates standardization, but I did not know for sure that the visualization was taking place at the app level of containers rather than the hardware level. Containers are also autonomous and are very secure due to their isolation.

From activity 6, one of the main things I saw that separates the two is that containers have images as a part of them and when a container is created, both the container and image are created. But when the container is removed, the image stayed while only the container was removed. The image cannot be removed on its own because it is being used by the container, stopping the container will not allow this either.

One quote from the post that I think best sums up the relationship between the two is “When discussing the difference between images and containers, it isn’t fair to contrast them as opposing entities. Both elements are closely related and are part of a system defined by the Docker platform.” There are things that separate them, but images and containers aren’t meant to be compared and contrasted, but to be used together to efficiently run the programs and data given from the Dockerfile.

https://phoenixnap.com/kb/docker-image-vs-container

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

This week, as we have begun to use Docker and explore how to use it further, I thought it would be a good time to look further into what Docker is and why it is used professionally. In doing so, I found a relatively short blog post by Sudip Sengupta called Introduction To Docker: A Beginner’s Guide that I think does a pretty good job of explaining the positives of using Docker as a development tool.

The post begins by covering why a lot of companies are switching to a containerized framework for development. Mostly, they explain, it is due to the ease of use. It allows for reduced complexity and vulnerability, and generally makes the development process more resilient to the introduction of bugs that are introduced by developers using different dependencies, or using different versions of different software dependencies. If developers are using Docker, they have a consistent container that is completely independent of what they have installed on their own system. So there is no variation in how a build will go, and no bugs can be introduced in the build process, making both building and testing more stable. The post also contains a brief but helpful explanation of how Docker actually functions. A customized docker image can be used to tailor instances of the container to use what is needed for development, and allow for a more modular work environment, as everything needed is stored in the image.

I chose this post because it felt like a pretty good introduction to what Docker is, how it works, and why it is being used more and more in professional software development. From my own experience using Docker so far, it seems like an extremely useful tool. There is no longer a need to have Java installed on my system just for software development, I don’t have to worry as much about what versions I have installed, or have to worry about having multiple versions that can introduce issues into my development. There just seem to be so many perks to using containerization, especially as part of a development team. After the initial setup of getting Docker to work, all the dependencies of your code are just stored in an image that can be used by everyone on the dev team. There is no longer a need to worry about somebody having an out-of-date version of something that can break the code, or cause inconsistent testing results. I will definitely continue to use Docker in the future, it just seems like an invaluable tool for any kind of software development, either personal or professional. And the amount of development tools that are made for Docker or can interact with Docker makes it even more useful.

Source: https://www.bmc.com/blogs/docker-101-introduction/

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.