Category Archives: CS-343

Software Architecture Patterns

Architecture of software systems is not something I’ve delved into very deeply in the past. For the most part, the systems I’ve worked on have been mostly self-contained and small-scale, and only recently, particularly in my work environment, have I been exposed to the importance and relevance of architecting the entire system in a smart manner, which involves much more than just the code lines within.

As I learn to develop larger-scale software, it becomes increasingly important for me to develop a capability of looking at the big picture, goals, and possible implementations of a desired software system. The number of individual moving parts just grows and grows when you need to accommodate logic, data, processes, and more, and I need to be as capable as possible of designing and implementing them, or otherwise working within them, while having an understanding of how they work, and how they affect what I’m making.

Software architecture concerns the overall structure of a system, including its components, relationships, and guiding principles.

The ultimate goal of thinking about your software’s architecture is to aid you and your team in creating the most performant, maintainable, scalable, and secure software systems possible for your use case and business requirements.

In order to learn more about architecture, I decided to take a look at a post on GeeksForGeeks that takes a look into the different types of architecture styles, their use cases, advantages and disadvantages, and inherent limitations.

https://www.geeksforgeeks.org/software-engineering/types-of-software-architecture-patterns/

The post explained how architecture patterns exist, just like design patterns do, and how they differ. Conceptually, the design patterns are lower-level implementation strategies, involving the individual components of a system, such as the Duck Simulator’s “factory” design pattern option. Architecture patterns, on the other hand, involve higher-level strategies for the entire software system, like the concept of client-server architecture, which will almost certainly now require some web-based components, or the concept of layered architecture, which involves splitting the system into four “layers”, the presentation layer, the business layer, the application layer, and the data layer.

Each architecture pattern has advantages and disadvantages just as the design patterns do. For example, the layered architecture pattern splits the system into four specialized parts, allowing for a more focused scope within each component, as in, the presentation layer is focused on UI components, and the data layer focuses just on data writing, retrieval, and storage.

Having a plan goes a long way when it comes to building software, and understanding architecture patterns is just another way to get better at planning, and working within, great software. I’ll continue to keep these concepts in mind as I create and work on more systems, and further my understanding of software architecture.

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

Unified Modeling Language (UML)

Hello everyone,

This week’s blog will cover Unified Modeling Language (UML) as this was a topic we recently covered in class and it was something that really left me in awe after learning about it so I wanted to write a blog about it. After finishing the homework about UML I realized how important of a tool it is for software developers and system designers. 

The author starts off the blog by giving a table of content to the reader. This allows them to get familiar with the structure of the blog, what it has to offer, and they can also jump on to a specific part that they want to read specifically. So UML is a standard visual language used in Software Engineering to model and design software systems. It helps developers, analysts, and stakeholders understand system structure, behavior, and interactions through diagrams. These can be extremely useful to people who are not familiar with coding and want to understand what the code does without being confused and lost when looking at it. The blog describes the purpose, significance, and the different types of UML, while also giving good advice and examples. On top of these, the author keeps a balance of technical explanation and keeping it simple for new learners. Later on the blog, he explains how UML closes the gap between technical and non-technical project members by providing a diagram which showcases the whole structure of the code and how everything is connected with each other. The article puts the history of how UML was created in the 1990s, and how the Object Management Group (OMG) took it as a standard. What I enjoy the most about this section is that it emphasizes why it is important, it improves communication, reduces misunderstanding, and helps in identifying design defects early. The blog then explains the various kinds of UML diagrams, like Class Diagrams, Use Case Diagrams, Sequence Diagrams, and Activity Diagrams. Both are discussed in detail along with their application, so it would be easy to understand when to use one over the other. The author also offers a step-by-step hands-on guide to creating UML diagrams, from deciding the purpose to using tools like Lucidchart.  The blog also has a dedicated section where it encourages the reader to practice and learn how to use UML. He states that it can be tricky at first, but with enough practice it will become easier to anyone. You can start off small and eventually you will get comfortable using UML when creating bigger projects

In conclusion, this blog was very informative and pertaining to my learning goals currently. Not only does the author describe what UML is, but he also takes readers through its actual uses, best practices, and even its limitations. Having this balance allows me to view UML as more than a diagramming scheme. It means thinking and planning effectively beforehand before starting to code..

Source: https://www.theknowledgeacademy.com/blog/unified-modeling-language/

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

Enhancing Code: Refactoring and Design Patterns

I chose the website Refactoring.Guru as my resource for this quarter’s blog post. This site offers an in-depth collection of material covering code refactoring and various software design patterns. The resource directly relates to course material in my Software Construction, Design, and Architecture class, as we recently completed an assignment that involved both refactoring and implementing three specific design patterns: Strategy, Singleton, and Simple Factory. I wanted to deepen my understanding of these concepts beyond the implementation done in my assignment.

Refactoring.Guru provides comprehensive guides on two core concepts in software development: Refactoring and Design Patterns.

Refactoring is the process of restructuring existing code without changing its external behavior, to improve readability and reduce complexity. This site thoroughly explains that refactoring is essential for resolving consequences of prioritizing speed over clean code, aka technical debt; and describes the various types of code smells and techniques for reducing them.

Design Patterns are reusable solutions to common problems found in software design. These patterns are sorted into three categories: Creational, Structural, and Behavioral; the website provides clear descriptions and examples of each type of pattern that falls into these three categories, including the Strategy, Singleton, and Simple Factory.

I chose this resource because I was amazed at the clear and concrete information it provided, and I felt the need for a more comprehensive foundation on these patterns outside of the practice the class assignment gave. I particularly enjoyed using the Singleton Pattern as it clearly visualized being the optimal choice for creating methods that respond to one instance class. Similarly, the Strategy Pattern was a great start in understanding how to refactor code by adding, swapping, and removing parts without needing to rewrite the entire program. This resource offers clear and visual explanations that help bridge the gap between how to implement a pattern and why it is the chosen solution in certain contexts. 

This website has, without a doubt, helped me better understand the reasons behind refactoring and the several types of design patterns. With the resources’ section on refactoring highlighting the seemingly tedious but essential effort of cleaning up code to prevent the accumulation of technical debt, it also helped me realize that refactoring is not just a fix for poorly written code or a skill to identify bad code, but is an essential part of writing good code.

As I continue completing in-class and homework assignments for this class, and develop and edit code in the workplace, I will refer to this website to not only identify the best design pattern, but to identify the design smells and technical debt- as these assignments help with strengthening those skills with pre-written code (that we then finish and/or refactor). I will use this resource to continue practicing design patterns and refactoring, to strengthen my skills and ability to select the right design pattern to refactor my code.

Resources:

https://refactoring.guru/ – Refactoring Guru

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

REST API design philosophy and constraints

Original Blog: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

For this post, I’ve decided to write about what qualities a REST API platform ought to have in order for it to best serve the clients that depend on it. I’ve chosen this topic since it relates to what I’m currently studying in my software and design class.

As of today, REST API platforms are among the most widely used kinds of web interfaces. This is largely because of the versatility they offer in what can communicate with the API. Because of this, some key characteristics and qualities have been noted as essential for most, if not all, REST API platforms to ensure no problems are encountered in using the API. In the blog, “Best Practices for API Design”, by John Au-Yeung, the author details some practices he feels are the most necessary.

The first listed quality is the JSON compatibility, which includes being able to receive requests in JSON and being able to respond in JSON. The main reason for this quality being essential are the fact that most networked technologies either do or can use it with minor adjustments, compared to other frameworks, like XML, which would require the transforming of data so that it could be used. This would be very cumbersome for both the client and the maintainers of the API, and is less preferable than just using an already widely used framework like JSON.

The second listed quality is to make sure the endpoint paths of the API include only nouns describing what an http method acting on that endpoint would affect. For example, a path for using the GET method on a collection of articles would just be called GET /articles/ as opposed to GET /retrievearticles/. Since the http method will always add a verb to the path name, extra verbs that just reiterate what the method does can clutter the syntax of the endpoints. While this quality is maintained, endpoints and their functions are clear throughout the whole API.

The third and final quality mentioned by the author that I’ll include in this post is use of logical endpoint nesting when making paths for related endpoints. This quality says that if there is related or grouped data that can be accessed, structure the paths so that it’s clear that the information is related. The example the author gave was when designing a path to access comments on a specific article, the path should resemble /articles/articles:id/comments. With this structure, it’s clear to the user where the information contained in comments in coming from, and how that information interacts with articles and a specific articles id. This quality is important because it minimizes the amount of possible confusion a user may experience when accessing child resources.

In summary, of the qualities the author chose to emphasize, the ones that stood out to me the most were the logical nesting of paths and the compatibility with JSON. The logical path nesting seems like it could also prevent the problem of users suggesting errors in the API itself, when in reality they’re just confused by the unclear path structure, and JSON compatibility just seems too convenient to not have, and way too cumbersome to operate without, especially if your API is seeing use on a large scale.

From the blog My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Understanding Concurrency from a Beginner’s Point of View

Concurrency is one of those computer science topics that, in theory, makes sense but somehow manages to be a little confusing in practice. In Concurrency 101: From a Beginner’s Point of View, Mrinal gives a straightforward and step-by-step discussion on how languages such as Python, JavaScript, and Go handle more than one thing simultaneously. My favorite was the way the author explained concurrency not as “doing multiple things at the same time,” but rather as making progress on more than one task without getting in each other’s way.

The article starts by explaining the distinction between concurrency and parallelism, a difference that is essential for authors of responsive programs to understand. Mrinal then discusses the mechanisms that support concurrency: processes, threads, and event loops. Each of these has trade-offs, processes are heavier weight but safer, threads are lighter weight with the risk of race conditions, and event loops (like JavaScript’s) rely on non-blocking operations to stay efficient.

There’s a large section on synchronization and how programmers prevent “chaos” when threads are reading and writing shared data. I liked the presentation of mutexes and semaphores. The chef example for describing deadlocks made it easy to see how two threads might be waiting for each other forever. Mrinal does discuss practical solutions such as lock ordering, timeouts, and try-locks, all patterns we’ve discussed in CS-343 when we’ve talked about safe concurrent design.

The post then moves to lock-free programming and message passing and explains how atomic operations and the Actor Model can eliminate many synchronization problems altogether. I liked how Mrinal mapped these concepts to real systems like Go’s concurrency model and Apache Spark’s distributed processes, and how scaling depends on understanding which workloads are benefitted by which model.

I picked this resource because concurrency has been one of the more daunting topics for me. Having the opportunity to read a post that was written from the perspective of another student made it that much more relatable. The analogies, along with real engineering explanations, bridged the gap between textbook theory and real implementation.

I took away from this blog to conceptualize concurrency as orderly cooperation between tasks rather than chaos waiting to happen. It opened my eyes to how careful design choices, like tidy lock ordering or message passing, can make programs more correct and speedier. In the coming times, I will apply these lessons when I am working on multithreaded assignments or any program that demands responsiveness, like my Android application that I made this summer which communicates with a Flask backend. Having the fundamentals of concurrency under my belt will allow me to write cleaner, safer, and more scalable code.

Resources: https://mrinalxdev.github.io/mrinalxblogs/blogs/concurrency.html

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

The Rest APi

 

The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The Rest APi

 

The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The Rest APi

 

The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The Rest APi

 

The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

APIs

Throughout my time in numerous computer science classes, API has been a common term that I’ve heard, but I never actually knew what it meant or what it did. I was happy to finally learn about it during class activities and in the introduction of Thea’s Pantry. I found an article by AWS explaining more in depth what APIs are.

What are APIs?

API stands for Application Programming Interface and is a mechanism that enables two software components to communicate with each other using a set of definitions and protocols, similar to the communication between the front end and the back end in Thea’s Pantry. The application sending the request is referred to as the client, and the application responding to the request is the server. In relation to Thea’s Pantry, the front end is the client making calls to the back end, which is the server in this case. Different types of APIs exist such as SOAP, RPC, Websocket, and REST. REST APIs are the most flexible and most popular, and are also the type that we are using in Thea’s Pantry.

REST API

REST APIs are so popular and flexible because the client sends requests to the server as data, and the server uses the client input to start internal functions and send output data back to the client. REST stands for Representational State Transfer and the API uses functions such as GET, PUT, and DELETE in order to access server data. These functions were seen and tested out in recent class activities. The main feature however is statelessness, which means that servers do not save client data between requests. This is a great benefit because it provides scalability, reliability, simplicity and many other key advantages. It is a very good idea to add security to APIs, and REST APIs can be secured by using authorization tokens and API keys.

How to use and API

The first step to using an API is obtaining an API key, which is accomplished by creating a verified account with an API provider. Next, set up an HTTP API client, which will allow you to structure API requests using the API keys. GET, PUT, and DELETE are all HTTP methods for the REST API as seen in class. Even if you do not have an HTTP client, it is still possible to structure requests by yourself in your browser by referring to the documentation of the selected API. And once you understand the API syntax, you are ready to use it on your code.

Source

https://aws.amazon.com/what-is/api

From the blog CS@Worcester – Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.