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 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 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 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.

For this week, I chose to read the pattern ‘Practice, Practice, Practice’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, practicing. I originally chose this pattern because it’s something that we need to reinforce within ourselves in order to get better at something, for coding especially. This is something I still struggle with due to my lack of drive and motivation but everyday is another day to push myself. Any way, the context of this pattern is wanting to get better at the things you do, to develop concrete skills. Again, just looking at the title gave away the context of this pattern, but that was it.

For the problem of the pattern, it is being unable to learn from your mistakes due to the performance of you daily programming activities, you feel like you’re always on stage. I assume this is in context of a job, but I haven’t experienced this problem yet so knowing about it ahead of time is going to help me down the line. For the solution of this pattern, you want to be able to practice without interruptions and in an environment that makes you comfortable making mistakes. This seems like an easy solution but in practice I’d imagine it’s hard. The solution also mentioned having a mentor to watch you over your practice and provide feedback. This is something I’d be interested in doing but I lack the humility to have a mentor watch me and provide me feedback, I’m always trying to do things on my own. I also dread looking at feedback because I feel I always mess something up, but I believe a pattern in the one of the previous chapters mentioned to put aside your ego, so I’ll have to go look at that one again.

Finally, for the action of the pattern, something I don’t write about often but I thought it would fit here, is to read one of the books that was previously mentioned in this pattern and take an exercise from it or make one yourself. The exercise should ideally be slightly harder than you can easily solve. You’ll then do this over 4 weeks and record your solution every time and over the 4 weeks you should observe how your solutions evolve. I thought this was an interesting take on practicing coding that I’ve never heard about. I usually just one and done exercises but repeating a exercise really cements it into your head so I’d imagine this way is much more beneficial to me.

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

Jennifer Gayle once said “You are the author and writer of your own story. Turn the page, start anew, and make sure it is a story worth telling”. In life, we have an open road that we are set upon. Sometimes there are factors that narrows that path. Upon reading Draw your own map, it has explained that we are not to be limited from outside factors. Such as a company with their own set expectations that conflicts on what you are interested in instead therefore, we must be more open to search for more opportunities. That it is alright to make modifications to our own maps to further gain motivation and values. 

I enjoyed the section of the solution for this matter; it piqued my interest where we must take the first step to make a motion forward. Even though it may be terrifying, but we must be willing and determined to walk forward. I also aggreged that we do not have make big goals that are broad but instead make smaller ones that can be achievable. This way we can make further adjustments to our map. It would not hurt to make bigger goals for long term but to break them down into small goals to conquer those bigger goals. There was not any part of the pattern I disliked as I believed this is very useful information. 

Using this pattern towards my life and career will be deeply considered when I go into the software development profession. To always remember that I can find many other opportunities that aligns with my interest of what I am looking for. And if it ever comes to fall out of place from my map that I will branch out my path even further to keep the love and interest I am intended to keep on going. Understanding that after having to trying out a new path and having a new set of values is essential to our mindset. To keep in mind that we ask ourselves is it worth it? Could this step hinder our truest potential? That is why we must keep expanding our choices and chose whichever is best in one’s interest.

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.