We’re preparing for a month-long final project in our Software Design, Construction, and Architecture class, which involves a static web app that utilizes a REST API. We’ve been going over what a REST API entails in some of our lectures, but I also wanted to read more about it so we are more ready for our project to begin. The tutorial that I used can be found at https://restfulapi.net/.

REST stands for REpresentational State Transfer, and it essentially defines a set of guidelines, or constraints, that a system must follow in order to denote a “scalable, fault-tolerant, and easily extendable system” (from http://restcookbook.com/Miscellaneous/rest-and-http/). So, a REST API can successfully handle client server requests and subsequent server responses by following 6 guidelines that are part of a RESTful system.

1. Client-Server – This is associated with the separation between client interface operations and server storage operations without them knowing about each other. This improves scalability of the system and flexibility of the client interface across different platforms.
2. Stateless – This means that the client and the server can still successfully communicate without taking advantage of any context outside of each request. In other words, both the client and the server do not need any prior requests or responses to still properly complete communications.
3. Cache-able – Data in a response from the server can be labelled as cache-able or non-cache-able; when cache-able, data from the response can be reused in other requests.
4. Uniform Interface – This simplifies the architecture of the system by separating its services into independent components: identification of resources (which requires each request to specify which resources, or data, it needs; this is done through the endpoint of a URL), resource manipulation through representation (which ensures that enough information is provided in the request to modify the resources presented), self-descriptive messages (which gives a message to the server that describes how to process the request), and hypermedia as the engine of application state (which provides information about navigating to each resource provided in each response from the server; for example, a link to the localhost may be displayed when returning a response about a local resource).
5. Layered System – This presents various services of the system in a hierarchical manner so that each component in distinct layers can only see the layers they immediately interact with.
6. Optional Code on Demand – This optional constraint allows the server to extend functionality of the client by responding with executable code to be run by the client, such as a JavaScript file or Flash application.

This article definitely helped me understand more about how the communication between a local client and a remote server works. I’m very excited for our final project to begin, especially now that I know more about the process behind it!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

We just wrapped up a section going over various design patterns used in software, so I wanted to do a bit more research on a different design pattern to get more of an idea about how they work. One pattern that looked interesting was the composite design pattern (https://howtodoinjava.com/design-patterns/structural/composite-design-pattern/), which appeared to combine a couple of concepts that I had seen from taking data structures: inheritance and trees. This structure of the composite design pattern essentially takes on the form of a hierarchy, with 4 types of items: a component, a leaf, a composite, and a client.

The component is the abstract entity in which common behaviors and operations are defined so that repeated code can be prevented. In the example provided in this post, a program to simulate the retrieval of banking information, the “component” expressed a list of other Component objects, methods to add and remove from such list, as well as other abstract and non-abstract methods that can be utilized by other classes extending from the component.

The composite and the leaf (or leaves) both inherit from the component. For this example, the CompositeAccount class served as the composite. This class implements the methods defined as abstract in the Component class. Because the composite and the leaves all inherit from Component, all of these objects from the different classes can be defined as Component objects. Thus, in the CompositeAccount class methods, all of the leaf objects are taken into account by traversing through the list of Component objects. For this example, the DepositAccount and SavingsAccount were leaves, with their own behaviors that were exclusive to the leaves.

Finally, the client puts it all together as the driver for this design pattern. New objects are created in this class, and each individual object is treated appropriately with the correct behaviors (i.e. the DepositAccount and SavingsAccount), while also being part of the bigger system, in this case the CompositeAccount, all of which are underneath the Component umbrella.

This was a great read for me! It was simple enough to understand coming from an extended introduction to design patterns and other programming courses using this kind of structure. I’m currently reading more about the Decorator design pattern for an assignment, so I hope to post more about that soon!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

In my last blog post, I briefly mentioned the idea of Test-Driven Development (TDD) as a process for creating programs, as well as its tying-in to Behavior-Driven Development (BDD). I wanted to learn more about TDD, so that will be the topic of this post! The article that I chose to read came from the following website: https://www.stickyminds.com/article/value-test-driven-development-when-writing-changeable-code.

This article touched upon concepts presented in both of the software development courses that I am taking (Software Design, Construction, and Architecture; Software QA and Testing). It highlighted the importance of making code that is easily changeable using techniques such as abstraction, encapsulation, or various design patterns. With this kind of coding strategy, developers don’t have to be as concerned about the whole program being affected when a few lines of code are revised. This is associated with more of the software design side of TDD. However, the process by which TDD takes place focuses on software testing, where further code is not written unless the automated and continuous tests produce a failing result. These tests are also written independently of the code being implemented. In other words, the code being tested is considered to be black-box, and the tests are made to uncover the failures in code, from which revisions will be made. This is where changeable code comes into play. This kind of coding mentality strives to ensure that the entire functioning of the program won’t break when the code is changed. This includes the automation of TDD; when the entire program is being rewritten because of a lack of changeable code, this may have additional effects on the testing process.

However, the article is quick to note that while TDD is a way to specify code behaviors by continuously testing and fixing code, it does not replace the process of Quality Assurance. With QA, the potential for code and tests to go wrong, as well as possible ways to navigate around these problems, are all considered. TDD is more “implementation-independent,” where the tests being run are not to assess the way behaviors are implemented in code, but in a more general sense, to simply express the behaviors that the program aims to implement. TDD, in a way, shows the specifications of a given program, and with continuous testing, can exploit the holes in a program so that they can be further improved.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

This week’s topic has to do with behavior-driven development, which a strategy of software development that focuses on the communicating narrative between developers so as to ensure that all members understand the specifications and other requirements of a program. I found an insightful article at the following website: https://airbrake.io/blog/software-design/behavior-driven-development. This blog post is one of a few in a series explaining different development techniques that work together as part of the software development life cycle.

As explained in the article, behavior-driven development, or BDD, works hand-in-hand with other strategies, such as test-driven development, which entails the execution of a failing test and then subsequently writing a minimum amount of code in order to pass the test. The BDD of tests becomes different from this technique when it relies more on the desired behavior of the program, rather than simply writing initially failing tests for all parts of the program, as utilized with test-driven development. BDD defines behavior specifications with user stories that outline various scenarios for the program to be executed or tested. These stories take on a narrative tone that states who and what are involved in each scenario, as well as the conditions that must be met in order for the scenarios to be successfully implemented. By using a common language understood and easily communicated by everyone on a development team, members can easily collaborate to define these specifications and perform tests based on the definitions given with the user stories.

This topic stuck out to me because it somewhat combined what I have been learning in both my Software Design and Software Testing courses this semester. This post discusses different methods of designing programs and their tests, and I thought that BDD clearly incorporated both, with the description of designing the behavior specifications to be met, as well as the concept of testing these specifications. We’ve somewhat been starting to take on both of these roles in the classroom by determining the purpose and desired functions of our programs, and then performing tests to ensure that the functions are working successfully. While we haven’t written out user stories to more specifically outline the behaviors, I think that this process is more implicit for us at this point.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.