Unified Modeling Language (UML) is an important tool in software development that helps developers visualize, design, and document the structure of their systems. It allows developers, project managers, and stakeholders to communicate with a medium that is easier to digest and explain. This week, I found a blog that introduces UML diagrams, “What is a UML Diagram?” from Miro. Miro gives an in-depth view of the types, benefits, and when to use UML diagrams.

Early in our course, we discussed and modeled Sequence and Class Diagrams. I chose this resource because of that foundation and because it is a great starting point for beginners. It also explained more diagram types than presented in class.

The blog explains that UML is a standardized modeling language used to visually represent a system’s design in a understandable way. It highlights two main types of diagrams, each with their own subtypes.

1. Structural Diagrams: These visualize the components in the system and their relationships. Some examples include:
   • Class Diagram: The static structure of a system showing classes, attributes, and relationships.
   • Package Diagram: Shows how packages and their dependencies are organized within the system
   • Deployment Diagram: Shows how software and hardware interact
2. Behavioral Diagrams: These visualize the system’s behavior over time. It is the dynamic behavior of the system. Some examples include:
   • Activity Diagram: Visualized the flow of activities within a system.
   • Sequence Diagram: Shows how objects interact over time.
   • Use Case Diagram: Shows the functionality of the system from the user’s perspective.

The post then describes the benefits of UML diagrams, such as simplifying complex ideas/code and improving team collaboration. It finishes by explaining the best practices and when to use UML diagrams.

This post helped me shore up my lacking knowledge of UML diagram types. I was unaware of most diagram types discussed, so it was nice to see what they were and how they were properly used. The site also provided a link to a diagram maker with some of the types which could be useful in the future.

The benefits were also insightful. The main takeaway was that the UML diagrams keep everyone on the same page. From the technically inclined to those lacking knowledge, you can communicate the system’s functions effectively. This seems especially true for those working in teams with different specialties. Having a roadmap for the system’s functions with a standard notation that everyone can understand allows the team to work more efficiently. In the future, I will use UML diagrams to keep everyone involved in our projects on the same page so we can collaborate to make our software more effective.

Resource: https://miro.com/diagramming/what-is-a-uml-diagram/#1.-simplifies-complex-ideas-and-systems

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

Backend development is the backbone of any software application. It handles the functionality behind the scenes, supporting interactions between the users and the application or website. The backend manages databases and server-side logic so modern applications remain efficient, scalable, and reliable. Understanding the principles of backend development is essential for developers to create effective software.

For this week’s post, I found a resource discussing key elements of backend development called “Mastering Backend Development” by Dan for Roadmap.sh. Dan introduces a roadmap for becoming an effective backend developer, and in this post, he discusses some of the steps on this roadmap in detail.

Backend development has been a key component of our class. I chose this resource because it is connected to the course, and the roadmap seems accessible to new developers. Having a path for your research and actionable steps to take can help with any knowledge gaps or roadblocks in understanding backend development.

This resource outlines 19 important steps or knowledge necessary for backend development. I have limited the summary to those I found interesting or instructive.

Caching Strategies: Improving the performance by storing copies of frequently requested data, reducing database load, and speeding up responses.

Authentication and Authorization: Ensures only authorized users access the system by implementing security measures.

Architectural Patterns: Picking the correct pattern, like Monolithic or Microservices, helps build scalable and maintainable systems.

Observability and Monitoring: Provide tools to monitor the system’s health, optimize performance, and diagnose issues.

Continuous Learning: Staying up-to-date with technologies, frameworks, and best practices. This ensures developers can adapt to the rapid evolution of backend development.

Some steps seem self-explanatory, but they could provide a good foundation for someone new to backend development. I could see how new developers could choose to prioritize the software’s functionality while forgetting its efficiency, security, and diagnostics. The post also offered plenty of tools to help with each step, like Redis and Memcached for caching strategies and OAuth and JWT for authentication and authorization.

I felt Dan gave an excellent synopsis of the research needed for new developers. Plenty of steps were not readily apparent to me, like cashing or your system’s self-diagnostics. These steps will likely present themselves in development, but for someone with little experience, it gives a good direction for research. This mindset aligns with the last step, continuous learning, and the importance of staying proactive regarding new challenges and technologies. In the future, I will research these backend concepts and stay up to date so I can produce and maintain better backend software.

Resource: https://dev.to/roadmapsh/mastering-backend-development-mpb

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

We have discussed REST APIs in class and are learning to use them with a practical, hands-on approach. This approach is faster for the course and is better for my understanding of the material, but I thought it would be a good idea to learn the history of REST APIs and expand my general knowledge of the subject. I found The Postman Team’s blog post, “What Is a REST API? Examples, Uses, and Challenges,” which discusses the fundamentals of REST APIs, including their history, standards, functionality, uses, benefits, and challenges.

The blog starts by explaining how REST APIs evolved from a simpler alternative to SOAP APIs, becoming the backbone of the modern web. With the advances in the internet during the early 2000s, developers and companies needed to be adaptable, which SOAP API was not the tool for. The post expands on the disadvantages of SOAP APIs and explains why they were less valuable at the time. SOAP APIs were not scalable and too restrictive, making it difficult for developers to innovate. REST APIs, on the other hand, gave companies and developers the flexibility and scalability needed to keep up with the internet as it evolved. Another key feature it had was independence. REST APIs are not tied to a platform or language and have client-server separation. The adaptability and simplicity made REST APIs an obvious choice for companies like eBay and Amazon.

The post also discusses some of the challenges involved with REST APIs. Some include maintaining consistent endpoints, managing multiple versions, and dealing with differing authentication methods. All these issues complicate the development and maintenance of REST APIs which is why there are standards used to mitigate problems in the future.

The blog’s final section showed REST API examples, including Amazon S3, Twitter, Instagram, and Plaid. It explained how each API has its own specialization, like Twitter’s registration process or Amazon’s ability for developers to incorporate AI.

What I found most interesting about the blog post was the timeline for REST APIs’ evolution, the big names that pushed REST APIs forward, and the reasons behind their actions. Major companies we know today, like eBay and Amazon, got ahead of the curve, leading the way for companies like Twitter and Facebook. Learning the reason behind its success and its practical uses was interesting. I will use what I’ve learned to approach future projects with a stronger understanding of REST APIs, ensuring I design scalable, adaptable, and efficient code.

Blog: https://blog.postman.com/rest-api-examples/

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

This week, I decided to discuss Application programming interface (API) documentation. API documentation is essential for developers to understand how to use the API, integrate it into their applications, and fix any issues that arise. The article “How to Write API Documentation: Best Practices and Examples” highlights the importance of API documentation and discusses practical insights into creating a better developer experience.

The article starts with an informative video discussing the API economy, what API documentation is, and how to write it. It also shows some examples. The article moves on to the common issues developers have with APIs, like being too long, too much technical jargon, un-updated, or inaccessible without registration. The author discusses several ways to remedy these issues by emphasizing that good API documentation needs to be user-friendly, clearly explained, and given examples with FAQs or tutorials. One of the strategies presented to accomplish this is called spec-driven development(SDD), where you generate the documentation while developing the API. We are also given several tools to help create and maintain API documentation, like Swagger and Postman.

I chose this article because APIs are discussed and used thoroughly in our course. The appropriate next step was understanding how developers make software accessible to users and, in doing so, become more accustomed to APIs.

Reading this article gave me several strategies to think over and included great explanations for why they are used. I was unaware of strategies like SDD and writing for entry-level users, but they made a lot of sense after reading the article. Creating the documentation after developing API can lead to errors and inconsistent documentation, frustrating developers. Having the documentation evolve with the creation of the API makes more sense. The explanation for writing with entry-level users in mind was great, too. You might think that all software developers understand API documentation, but each developer has their own experiences, specialty, and knowledge. Tailoring the documentation to everyone is impossible, so aiming for clarity at the entry-level will make it understandable for most developers. It is one thing to hear how to improve your documentation, but seeing data on the main features developers want and issues they get frustrated with makes me feel like the strategies will have a greater impact on the users.

In future projects, I plan to use spec-driven development to ensure my API documentation grows with my project, allowing developers to follow along without confusion. I will also aim my documentation at entry-level users so the resource is accessible to most developers.

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

Like my previous blogs about performance and AI tools, I wanted to discuss another area of software testing that covers a specific development aspect. I chose security testing because while performance and functionality are essential, we must ensure our applications are safe for their users. This blog post, “Security Testing: Types, Tools, and Best Practices,” by Oliver Moradov, will outline various aspects of security testing, its importance, and its methodologies.

Oliver’s blog starts by defining security testing, listing its main goals and principles, and providing an index for many other aspects of security testing. It stresses that security testing is a non-functional testing process that determines the resiliency of software from cyber-attacks and data breaches. Non-functional testing focuses on how the system works rather than if it works. The primary goals are identifying assets, threats, vulnerabilities, and risks and performing remediation. 

The blog then discusses the types of security testing, including penetration testing, application security testing, API security testing, and vulnerability management. It also covers security test cases, and security testing approaches such as black box, white box, and grey box testing. The blog finishes by discussing best practices in security testing, such as shifting security testing left, testing internal interfaces, and automating tests.  

 I felt the distinction between functional and non-functional testing was important to discuss. Knowing how our data or the company’s data is handled is much more important for security than making sure the software functions correctly. It could function perfectly within the development team’s parameters but still fail to protect the company’s and users assets. 

I found it interesting that black box, white box, and grey box testing are applied differently than how they’re typically used in unit testing. The fundamental uses are the same, limiting and granting information, but there is much more to be gained when using this method in security testing. Testing what a malicious hacker could do with limited or abundant details on the software would be critical to protecting our assets. It also highlights the difference between non-functional and functional because developers use box testing to determine how to make errors occur within the system. In contrast, security tests would use the system functionality itself to create a breach in security. 

The sections detailing what security vulnerabilities they look for were enlightening. The authentication, input validation, and application logic sections highlighted what scenarios the security tests may encounter to validate system safety. I’m glad the blog discussed tools for developers to ensure their code can’t be exploited. Overall, this blog gave plenty of rudimentary information on security testing, and I urge those interested to check it out. In the future, I plan on using the tools and testing techniques to ensure that my code is safe for its users and owners. 

Blog: https://brightsec.com/blog/security-testing/

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