The Unified Modeling Language (UML) is a standard for diagramming the design of a computer program. UML class diagrams illustrate the classes and relationships of an object-oriented program. The five fundamental class relationships are dependency, aggregation, composition, inheritance, and realization. When my professor introduced UML, he provided instruction on inheritance and realization. Because an understanding of the five relationships is essential to reading and building UML class diagrams, the goal of this post is to familiarize myself with dependency, aggregation, and composition as well as their applications. To achieve the goal, I will be reflecting and adding to the blog, “Association vs. Dependency vs. Aggregation vs. Composition,” written by Niraj Bhatt, an enterprise architect at Advent eModal. In the post, Bhatt defines and applies the relationships.

Dependency is a relationship between two classes where one class uses the object of another class as a parameter of a method. One can represent it by drawing a dotted arrow from the user class to the class being used. Bhatt exemplifies the relationship in a program that simulates a turn-based game. The program acquires a Player class with a TakeTurn method that expects a Die object. Bhatt’s example is effective because, in many turn-based games, a player uses a die during his or her turn.

Aggregation is a relationship between two classes where one class owns the object of another class as an attribute. If an instance of the owner class ceases to exist, the object of the other class would still exist. One can represent it by drawing a line with a hollow diamond from the owner class to the class being owned. Because Bhatt exemplifies the relationship in an unfamiliar type of game, I will be providing another example. Another application of the relationship is in a course management system where the Course class owns Student objects. The application is effective because students will exist when courses do not.

Composition is a relationship between two classes where one class needs to have an object of another class as an attribute. If an instance of the former ceases to exist, the object of the latter class would cease to exist too. One can represent it by drawing a line with a filled diamond from the owner class to the class being owned. Because Bhatt exemplifies the relationship in an unfamiliar type of game, I will be providing another example. An application of the relationship is in an online shopping system where the Customer class has Order objects. The application is effective because orders would not exist without customers.

If I continue to pursue a career as a software engineer, my newfound understanding of class relationships will help me carry out my responsibilities. Many companies use UML to illustrate their software systems. I may need to apply the relationships to blueprint software or understand them in existing software to implement new features.

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

When writing code, it is always important to write as cleanly and efficiently as possible. Code can be sometimes confusing and hard to read to begin with, and writing poor code makes it much harder. We measure the quality of code using design smells. Design smells are different metrics such as rigidity and fragility which measure how poor a certain part of design is.

Yonatan Fedaeli writes in his article “Software Design Smells” that there are seven main design smells: rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity. These smells exist in all code to a certain extent, but some code has much less smells than others. The goal is to limit each of these smells as much as possible.

Rigidity is software’s inability to change. This makes it very difficult to add new features to a project. An easy way to fix this design smells is by designing each section of software independently of each other since the more interdependence a project has the more rigid it will be.

Fragility is a software’s tendency to break whenever a change is made. This is similar to rigidity, but different in that it is not difficult to make the change but difficult to make the change work. Any small change can totally break the entire project in a very fragile design.

Immobility is a project’s inability to reuse components. When a project is immobile, each piece of the project is so dependent on the rest that is almost impossible to use it in a different context. When writing a large project it is important to reuse code so that you are not wasting time writing the same thing multiple times.

Viscosity is how closely a project follows the original design goal. When a project is very viscous each new feature either preserves a complex design or does not follow the design goal. When a project’s environment is viscous it means that the project exists in a complex work environment. It may be difficult to build or test and you may spend extra time trying to get the project to run.

Needless complexity is when a project is more complex than it needs to be. Software is already complex to begin with, and it is important to write clear code so that people reading it do not need to spend extra time trying to figure out what it does.

Needless repetition is when code is repeated multiple times when it could be abstracted. This is similar to immobility in that code is not reused, but different since this smell focuses on abstraction and how code does not need to be rewritten many times.

Opacity is a project’s inability to be understood by the developer. This is similar to needless complexity in that an opaque project can be needlessly complex, but includes much more than that. Usually an opaque project has a poor initial design which is why it is difficult to understand.

When writing code it is important to write clean, efficient code. Keeping design smells in mind when coding will keep your projects clean and good quality.

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

This is the Keynote speaker for day two of Raleigh ISSA’s 2021 Information Security Conference. In my previous post about the Keynote of Day 1 Keynote Speaker I detailed my attachment to the Association and my appreciation for the monthly resource of meetings that I used to attend when I lived in Raleigh. The presentation for Day 2 is a little different in that it’s not themed around Halloween or any comedic points.

The speaker, Armando Seay, is a Co-Founder & Board Member at Maryland Innovation and Security Institute which is an organization that assists clients in finding security solutions and applying them to their IT infrastructure. He begins the presentation discussing the importance of understanding security standards and practices around the world and how young professionals in the IT field get their starts in the US, Ukraine, Israel, and other various countries. He describes his organization as “geographically boundless” due to the fact that they assist clients all over the world.

The importance of being able to work with people around the world is something that I’m finding to be more and more important as I travel around the US from one cultural hub to another. I grew up in Columbia, South Carolina and then I joined the Coast Guard after High School and now I’ve moved to Worcester. Each of these places are full of different demographics and being successful in each of them required working with different people from different backgrounds and finding common ground to build upon. I have friends that were born in Haiti, China, West Africa, Europe, Canada, and they all come from backgrounds that are exceptionally different from my own. Engaging with people from different backgrounds allows one to broaden their perspective and find solutions that they wouldn’t normally find on their own.

Armando goes on to talk about the Academic Partners and what they call their “Partner Ecosystem,” I believe that POGIL team structures kind of works as a microcosm of these in that when groups are switched around we form partnerships that we can maintain and use to better understand our assignments and accomplish goals.

One thing that I found particularly interesting was his discussion about Maritime Attacks, that is to say attacks on the software that ships use to either catalogue their cargo, their navigation, or even their movement. It’s important to be aware of software vulnerabilities and best practices so that we aren’t exposing others to cybersecurity vulnerabilities due to our negligence. Armando closes his presentation discussing Zero-Trust policies and how critical it is to verify any process or user in your network and everything you do before you entrust any security clearance to them.

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

This week, I have a chance to work with JavaScript files of a backend in my homework-5. However, there were many syntax that I had never seen, so I got no sense when I was writing code. Thus, I looked for some resources to satisfy my curiosity and to get a better understanding of JavaScript.

JavaScript Tutorial is one of the resources that I find useful because it provides all the information related to JavaScript. First of all, from the website, I know that JavaScript is one of the most popular programming language of the web. It is used to program the behavior of a web page. Next, according to the website, I can look up and learn more about new syntax or new definitions of JavaScript respecting to my homework 5. For example, the keywords “let” and “const”, Array Iteration, Async/Await appearing in my homework make me question that what they are for and why they are there in the .js files.

However, based on the information from the website I can answer those questions. It said that “let” is used to defined a variable, whereas “const” is used to define a constant variable which cannot be reassigned. Every “let” and “const” variables cannot be redeclared and have block scope. For the Array Iteration, JavaScript has many methods to operate on every item of an array, such as map(), filter(), reduce(), every(), especially forEach() which I have met in my homework. forEach() is used to apply a condition or a function inside the parenthesis to each element of an array. For Async/Await, it said that “async” is used to make a function return a promise, and “await” keyword is only used inside the “async” function. “await” will make a function wait for a promise. So, what is a promise in JavaScript? Promise is a JavaScript object that links producing code and consuming code. The below picture is an example given by the website to explain clearly what producing code and consuming code are.

In conclusion, in my opinion, this website is one of a good resources to help me learn more about JavaScript. It includes all the information that I wanted to know and it also explains clearly every new definition with easily understandable examples. Thanks to this website, I am getting more familiar with JavaScript and get a better understanding of the code given in my homework-5. So, I believe that this website will give me a good foundation to work with my homework-5 or with any .js files.

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

blog.ndepend.com/10-reasons-why-you-should-write-tests/

For as long as I have been aware of it, I have been skeptical of the value of software testing. It has always struck me as unnecessary busywork, mostly because that is how writing them for my classes feels (granted, that’s generally how writing code for any class feels in my experience). Either the program works or it doesn’t, right? Why bother writing a test when you could use that time to tighten the ratchet on the code you’d otherwise be testing, or even move on to something else?

In an attempt to broaden my horizons, I sought out some arguments in favor of testing. One idea I found, from Avaneesh Dubey (which he discusses in the above article), is probably the one I personally find the most compelling. He argues that the hallmark of a poorly constructed test case is essentially one that is too narrow in its scope or the functionality that it covers. Proper tests, he argues, must reflect “usage patterns and flows.”

Jumping off of this, I would articulate this slightly differently. I think that proper testing methodology would necessarily force developers to be aware of the boundaries they want to encapsulate between. For example, it would be kind of absurd to write tests to make sure a factory class works correctly, because whether or not you’re even using the factory paradigm is almost certainly too technical for non-technical product managers to care about. My understanding of testing is that it’s primarily a way for this kind of person to make judgments about the development process independently of the actual developers.

When you write software tests, you are, or at least should be, asking yourself questions about the high-level flow of the program – what it’s actually doing in physical reality rather than very tiny implementation details – and that is ultimately where your head should be at all times during the development process, in my opinion.

Though obviously, test writing is an important skill for actual work in the industry, I had no intention of ever writing any tests for my personal projects. Now, I’m not really sure that I’m sold on it for personal use, and I’m still a little skeptical about the efficacy of test-driven development in single person projects, but I think it might be of some use to me. In particular, I hope it can help me make some sense of the WebGL code I’m planning to write for a project in the near future, which is certain to contain many fine technical details that can quickly become a headache if not managed properly.

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

For this week’s blog, I was looking more into API since we covered this in the class to know more about it. Application programming interfaces (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. API enables companies to open their applications data and functionality to external third-party developers, business partners, and internal departments within their companies. This allows service and application to communicate with each other and leverage each other’s data and functionality through a documented interface, developers do not need to know about how the API is made because they will simply use the interface to communicate with an application and web services.

How an API works: API stays between an application and web server, acting as an intermediary layer that processes data transfer between systems.  APIs are sometimes thought of as contracts, with documentation that represents an agreement between two parties, if one party sends a remote request structured a particular way, this is how party two’s software will respond.  For example, imagine a medical equipment distribution company. The distribution company could give its customers a could app that lets the hospital’s employee check a certain equipment availability with the distributor. The app could be expensive to build, limited by platform, and require long development times and ongoing maintenance. This has several benefits like it lets the customer access data via an API which helps to check information about their inventory in a single place saving time, The distributor can make changes to its internal systems without impacting customers, with a publicly available API it could result in higher sales for the business.

In short, APIs lets you open up access to your resources while maintaining security and control. How you open access and to who is up to you. There are four main types of API those are Open API, Partner API, Internal API, and Composite API. Open APIs are open-source application programming interfaces you can access with HTTP protocol. Partner API are application programming interfaces exposed to or by strategic business partners. Internal APIs are application programming interfaces that remind hidden from external users. Composite API combine data or service APIs. I used this article because it explains API in an easy way, explains about it giving an example which then makes it’s more clear. And in today’s world innovation is very important as technology is increasing day by day so knowing about API is helpful in the future as it helps in fast innovation.

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

This week, I wanted to solidify my understanding of the concept of REST or RESTful APIs, what they are, and how they work. There is a plethora of information on this topic but I’ll be referring to a blog post by Jamie Juviler and a website on REST API that I found helpful.

Before we get into what REST is, let’s first go over what an API is. API stands for application programming interface, and they provide a way for two applications to communicate. Some key terms include client, resource, and server. A client is a person or program that requests the API, to retrieve information, a resource is any information that can be returned to the customer, and a server is used by the application to receive the requests and maintain the resources that the client is asking for.

REST or RESTful is an acronym for Representational State Transfer and is a term used to describe an API conforming to the principles of REST. REST APIs work by receiving requests and returning all relevant information in a format that is easily interpretable by the client. Clients are also able to modify or add items to the server through a REST API.

Now that we have an understanding of how REST APIs work, let’s go over what makes an API a RESTful API.

There are six guiding principles of REST that an API must follow:

1. Client-Server separation

The REST architecture only allows for the client and server to communicate in a single manner: all interactions are initiated by the client. The client sends a request to the server and the server sends a response back but not vice versa.

2. Uniform Interface

    This principle states that all requests and responses must follow a uniform protocol. The most common language for REST APIs is HTTP. The client uses HTTP to send requests to a target resource. The four basic HTTP requests that can be made are: GET, POST, PUT, and DELETE.

3. Stateless

All calls with a REST API are independent from each other. The server will not remember past requests, meaning that each request must include all information required.

4. Layered System

    There can be additional servers, or layers, between the client and server that can provide security and handle traffic.

5. Cacheable

REST APIs are created with cacheability in mind, when a client revisits a site, cached data is loaded from local storage instead of being fetched from the server.

6. Code on Demand

In some cases, an API can send executable code as a response to a client. This principle is optional.

If an API follows these principles, then it is considered RESTful. These rules still leave room for developers to modify the functionality of their API. This is why REST APIs are preferred due to their flexibility. RESTful APIs offer a lot of benefits that I can hopefully cover in my next blog post. 

What is REST

What is an API?

REST APIs: How They Work and What You Need to Know

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.