Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

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

Unified Modeling Language is a standardized language to visually represent software construction, design, and architecture. UML designs are process independent, and often omit irrelevant, or insignificant relationships and attributes in favor of simplicity. UML diagrams can be used to represent a variety of things in several ways. UML diagram can be classified into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the relationship/interaction between those objects. Structure diagrams are to be considered descriptive and behave like a blueprint for the code, i.e., it can be used to inform the design of written code. Class diagrams are one of the most frequently used Structure diagrams in software development. It shows each of the classes in a system with their attributes, class methods or operations, the scope of every attribute and method within a class, and the relationship between two or more classes. A class diagram has three parts: Class Name, Attributes, and Methods. The name of the class is always at the top, while any attribute like a variable is in the middle. A note can be added pointing to the attribute to show any individual specification or requirement. The methods are listed at the bottom and can similarly have notes pointing to the method to show any individual specification or requirement. Arrows are used to describe the relationship between two or more classes. Depending on the arrow the specific relationships can be identified. The various relationships are Association, Dependency, Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system and any objects it contains. They describe how those objects should interact with each other to make the system functional. Behavioral diagrams are considered prescriptive, i.e., they show how the written code should work in the system.

As a CS student, I found thisblog post on UML diagrams to be highly relevant and useful. Homework 1 and Homework 2 provided a great opportunity to delve into the complexities of these diagrams and gain a deeper understanding of their various properties and concepts, especially for Class Diagrams. It will very likely be useful in future classes as UML diagrams allow you to be able to communicate your design ideas effectively to other members of your group, ensuring that everyone is on the same page and working towards the same goal. They can also be a valuable resource for documenting and maintaining software systems, making it easier to understand and modify the system as needed. For example, the visibility of attributes and the connections between classes, as represented by arrows, are crucial elements that contribute to the overall coherence and functionality of UML diagrams. Additionally, the provided examples helped to clarify and illustrate these concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

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

This week I learned about anti-patterns by reading “Anti Patterns” by Ilyana Smith. Smith explains “An Antipattern is a description of a “negative solution” and a corresponding “positive solution.” In other words, an Antipattern describes a common way of solving a problem that actually causes more harm than good, alongside an example of a better way to solve that problem”. Smith then gets into the details about each pattern and the problems they cause.

Smith tells us that there are seven deadly sins of software projects that are the root causes of problems. These “sins” are haste, apathy, narrow-mindedness, sloth, avarice (overcomplicating things), ignorance, and pride. There are 18 anti-patterns Smith talks about. These anti-patterns are analysis paralysis, architecture by implication, the blob, copy-paste programming, death by planning, design by committee, functional decomposition, functional decomposition, golden hammer, intellectual violence, lava flow, and poltergeist, reinvent the wheel, spaghetti code, stovepipe enterprise, Swiss army knife, vendor lock-in, and singleton.

As you can see, there are a lot of anti-patterns. I will not be able to describe all of them so I suggest reading the article yourself, but I will go through a few of them. Analysis paralysis is when a software team gets caught up in the design and planning phase and fails to start any development.  The blob is building a class that does most of the work and there are a few secondary classes that contain mostly data. Copy-paste programming is a problem because if there is a problem in the code you copied it will be everywhere you paste it. These are just a few of the many anti-patterns.

After reading about the seven deadly sins of software projects and the anti-patterns associated with them and how important they are. I also learned there are a lot of things I should avoid when working on a project. Some of these anti-patterns could be easy to get caught up in like analysis paralysis. Being too caught up in trying to get the perfect design is something I could see myself doing so keeping these patterns in mind is something I should do. I think Smith did a great job explaining these patterns in a way that is easy to understand but still gets the point across. I would recommend this post to any software developer looking to improve their skills. Even if only one of these patterns is a new concept, I am sure it would be worth the read.

Link: https://ilyana.dev/blog/2020-11-24-antipatterns/

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

For this week, I decided to look at freecodecamp.com’s article on REST APIs. We are currently learning how to use and work within REST API environments, so I assumed that this article would just be review, but I have learned some new topics. The article essentially describes what REST API’s are and how they work. Before delving into REST APIs however, the article explains what API’s are. Essentially, they are a middle man between the user and an application regarding information. The article uses a customer at an unknown restaurant for an analogy. The server is the API, and the customer is the user. The user requests a specific item from the menu, or the API’s documentation, and the server brings that request to the kitchen, or the application, and then returns with the user’s order. Rest API’s are specific to web servers only, and use a set of 5 different HTTP functions to perform their operations, GET, PUT, PATCH, DELETE and POST. All of these essentially create, read, delete and update information. These features allow the user to alter and gather information from a web server from a simple application and without having to go into the actual code to do this, after the REST API is set up. The information is then returned to the user in either a json or XML format.

I picked this article due to its simple yet effective explanation of what REST APIs are. As stated before, we are currently working with REST APIs in class, so a lot of this article was review, but this article expanded my way of thinking how REST APIs work. I have used freecodecamp’s articles in the past, and they provide free and simple explanations for complex software topics that are very beginner friendly. The article also included real code examples of how to use some of the requests, along with a different method of using the requests than from what we learned in class by using the fetch API.

This article will help with my work in REST APIs thanks to its clever ideas in how its explained. I have never thought of the restaurant analogy, and I am sure it will help with learning more about REST APIs, and when I am explaining to my friends or family what it is I am doing in school, I can lead them to this article to help their understanding.

https://www.freecodecamp.org/news/what-is-rest-rest-api-definition-for-beginners/

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

A bridge is a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchical abstractions and implementation- which can be developed independently of each other. The blog from refactoring guru explains bridges a way of using more object composition rather than inheritance. Which means that we can extract one of the dimensions into a separate class hierarchy, so that the original classes will reference an object of the new hierarchy, instead of having all the behaviors with in one class.

Using this design principle, we can extract the code into its own class with two subclasses. And then we can have a reference field pointing to one of objects. That reference field will act as a bridge between one class to another and let’s say we needed to add another color for a shape, then we don’t have to go out of our way to create a PurpleCircle Class, we can just add the color, reference it with the shape and we’re done.

The blog has gone out of its way to explain real world applications for the Bridge pattern. One being used to help divide the monolithic code of an app that mages devices and their controls. The Device classes act as the implementation, whereas the Remotes act as the abstraction. The remote-control class declares a reference as explained in the description and that links it with a device object. All remotes work with the device via the general device interface.

Bridges are important because sometimes it can get hard to see what is contained with in a class especially if the class is gigantic. And making changes with one aspect of the class could require you to make changes in other aspects of the class. So, the bridge helps split the monolithic class into several class hierarchies. Which makes it different then most patterns like the Factory Design pattern or the Singleton pattern. The Bridge pattern would be mostly compared to the Strategy pattern where it plays a bigger role in how the code is being structured rather than adding some small commodities. It’s important to use the Bridge pattern to help extend the class in several orthogonal (independent) dimensions. It helps delegate the original class into related work to the objects belonging to those hierarchies instead of doing everything on its own.

The Bridge is very useful to help organizations within the code, I always tend to fill my classes with code with the use of implementations or inheritance so this would be a good way to get myself started on it.

Link to Blog: “https://refactoring.guru/design-patterns/bridge”

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

This week I read about frameworks by reading “What’s a framework? All about software frameworks” by Lucas Stahl and Sean Higgins. Sean and Lucas did a great explaining what a framework is by making it easy to understand and giving many examples.

A framework is like a template that can be used to build your code on top of. Frameworks are premade code that take care of some aspects of the program. They are also reusable functions that make programming easier. Most programming languages have at least one framework that use them. The content of a framework can be very different, and it depends on the needs of the programmer for which one they should use. Many frameworks are open source that are maintained by the community of programmers but there are some from large companies like Microsoft or Meta. Frameworks might sound like code libraries but there is a difference. A quote by David Fateh helps explain the difference. Fateh said, “A framework,” he says, “is like a construction blueprint: A template that defines a basic structure for your build. A code library is more like a carpenter’s tool belt: It has tools designed to perform specific tasks”.  Lucas and Sean go on to explain the benefits of using a framework. Some of the benefits are being able to focus on one area of development, easier testing, development speed, reliability, documentation, and better security. There are many benefits to using frameworks but there are a few challenges as well. These challenges are structural limitations because frame works can’t do everything, having to learn the framework and the language it is based on, as well as having to pick from the many frameworks that are available today.

I learned a lot from this article, and I think frameworks could be a useful tool to use when programming. The diverse selection available seems like they could help in many situations. Being able to use a framework to cover a part of a program like the backend for example so another part like the front end can be focused on sounds interesting. Being able to focus on your area of expertise is a major benefit of frameworks. Although there are some limitations of frameworks the benefits seem to outweigh the cons. After reading this article I am now curious about all these frameworks and how I could use them to better my development skills. In the future I suspect that frameworks will be a common use for me.

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

This week, I decided to look at an article based on the GRASP principles, and found this insightful article from Kamil Grzybek, an experienced designer in the .NET Framework. The GRASP concepts essentially explain how to assign certain responsibilities to different classes within a project. Each principle is derived from a problem, and the principle solves the problem. The first principle, Information Expert, decides which class will take the responsibility for a certain operation. In his example, his Customer class takes the responsibility of compiling an order since it has all the necessary information to do this. The next principle is Creator, which asks the question who creates an object? The answer according to the principle to assign a class to create this object, only if said class is closely related to the object. The next principle Controller decides who is the first object beyond the UI to control a systems operation and delegate information. The fourth and fifth principles are Low Coupling and High Cohesion, which solve the issue of keeping classes independent and to keep them focused on minimal tasks. The sixth principle is Indirection, which solves the issue of avoiding direct coupling between objects. The seventh principle is Polymorphism, which helps control flexibility within the code. The eighth principle, Pure Fabrication, solves the issues of what do to when there is an intermittent task that needs to be completed and avoiding more direct coupling between classes. The final principle, Protected Variants, is argued to be the most important principle. It helps to keep code available to change.

After reading this article, it seems to be a more expanded version of principles and concepts we have learned earlier in the class. Most of the principles within the GRASP lineup are connected to either another set of principles like SOLID, or directly correlate to a specific concept like loose coupling. The main reason I selected this article was the nice use of physical code examples to show off the principles. Throughout the whole article, Kamil used a Customer project that tracked orders. Each concept was show in a different section of the project, which makes it easier to visualize when thinking about how to apply it to code that I create. This article seems more to be for more experienced software designers, which I enjoyed. Learning new concepts with descriptions that are easy to understand can be helpful, but having a more challenging description given to me challenges me to understand the concepts deeper.

To use these principles in the future I must remember a two different ideas.
1.) All aspects of the code need to be individual and loosely related to avoid breaking the code when adding change
2.) It is easier to assign certain tasks to a separate class than to jam pack a single class with all of the functions

Link:http://www.kamilgrzybek.com/design/grasp-explained/

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

This weeks blog read of choice was a blog called “ Polymorphism in Programming” by Jonathan Johnson. This blog goes throught what is polymorphism, how to use them and also the different types that there are. One thing I thought was funny is that it compares ciderella after midnight m and before as polymorphism. Since polymorphism is when the object undergoes transformation. In programming the oject tranforms in compile time and dynamic and what does the transfmation is the method and object. Polymorphism is very essential to object oriented programming. Four different types of polymorphism are subtypes polymorphisms, parametric polymorphisms, and hoc polymorphisms and coercion polymorphisms. Subtype polymorphisms is the most common kind, it uses of class name to refrenece multiple kinds of subtypes at once. Parametric polymorphism which is also describe as overloading specially provides a way to use one of its functions to interact with multiple types. Ad hoc polymorphism also known as compile time the function with the same name acts differently for different types and lastly there is coescion polymorphism is the direct tranfomation of one type to another this happens when one type gets cast into another type. The reason why I picked this blog post was because we went over polymorphism in class a while back but I personally did not take the time to dig deeper into the subject so this was a good opportunity to dive a little deeper. Which is what I was able to achieve with this blog post. It refreshed what I learned about the different types of polymorphism and really helped me grasp the concept into a more deeper level. The reason why I picked this blog post is because I like the way it was formatted and how it is organized with its information. I also like the graphics that they used to explain it. It brought a simple and a more clear picture. Especially when they used Disney to connect to reader. I really appreciated that, it brought a sense of light weight to the read. There was a lot of information but it was easy to intake because of the organization. I hope to take a lot from this blog post, and use polymorphism to reuse code more effectively, to also use same variable for multiple date types. And also to reduce coupling with differently functionality types. Hopefully these clarification with different types help me excel in this so that when I do need to reuse code I can do it in the best format possible using all the architecture structures that I am learning. 

https://www.bmc.com/blogs/polymorphism-programming/

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.