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.

The Testing Automation Pyramid (sometimes just called the “Testing Pyramid”) is an Agile methodology that involves a heavy reliance on Unit Tests as opposed to UI-based testing. It’s referred to as a “pyramid” because the width of the layers in the pyramid refers to the ideal number of tests per layer. The bottom, widest layer is Unit Testing, the middle layer consists of service-related tests, and the tip of the pyramid represents UI Tests. A picture of the structure is shown below, sourced from Martin Fowler’s blog.

Moving up the pyramid, the type of testing done costs more resources to execute and more time to assess.

Part of the reason why UI testing takes significantly more resources is because it involves interacting with and logging the operations of the interface in order to see where something may go wrong. Running through the operations of the UI to see where it breaks takes a very long time, as there are so many levels of abstraction between the UI and the underlying infrastructure, and so much functionality within User Interfaces. On top of this, as the product is updated and refactored, tests derived from the original UI interface becomes obsolete, making the lifespan of higher-level tests shorter than those aimed towards the low-level structure of the system.

This is why Unit Tests are so good. They’re a cheaper (in terms of both resources and time) alternative, and they provide a means of testing the actual root of the issue. Unit Tests are preventative and they ensure that a bug presenting itself in the UI level stays fixed, rather than allowing the bug to manifest itself in a variety of different ways.

There is quite a bit of criticism of this model, as if it goes unchecked it ends up as the so called “Ice Cream Cone” anti-pattern, where a small layer of exploratory manual testing above the UI testing layer ends up becoming mandatory manual testing, which becomes both a resource and a time sink. This is far better explained by viewing Alister Scott’s blog post on it over at his blog, WatirMelon.

Martin Fowler, whose blog I found this concept on and referenced earlier, summed it all up in a pretty wonderful way: “If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test.” Martin’s blog post elaborates on the idea much better than I’m able to, and his blog is extremely readable and has really great content. I’ll definitely be using it as a resource in the future.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

http://thetesteye.com/blog/?utm_source=fuel&utm_medium=referral&utm_campaign=lrfuel

This week I read the introductory blog post from The Test Eye, written by Martin Jansson in 2017 as a description of the authors goals and intentions as he writes further posts. In the post linked above, Jansson describes the pros and cons to agile frameworks in his opinion as a professional tester.

Firstly, Jansson states that a main advantage in an agile organization is that no single person bears the blame for the overall quality of the final product, if it happens to fail or come short of expectations. It takes a team where the result is everybody contributing their own level of effort into the project, which is a very good concept for a team building environment. However, Jansson believes there can still be improvements within the framework.

Jansson expresses that these frameworks are meant to be altered and changed dynamically to fit the specific situation appropriately. If the agile transformation is followed exactly, there will be circumstances where it will fail since they have limitations, so its important to be flexible in that way with this kind of environment.

He continues by explaining that coaching in an agile organization also proves difficult fundamentally, since no one person can be an expert in all necessary fields. Rather, its more efficient for this expertise to come from within each department to guide implementation. This approach is supported by the fundamental concepts of an agile framework, where change and improvement over time are stressed.

Jansson then critically assesses the inclusion of testing in frameworks such as SAFe. He believes they could improve by including more various testing material, since currently there isn’t much of any content about testing. He also shares that testing is undervalued currently and is misrepresented as something “everyone is expected to work with.”

Although he has these criticisms, Jansson still admires many good ideas and material laced throughout the frameworks. His goal is to suggest improvements and adjust them as agile transformation continues into the future. I will continue to follow these posts since the writing style is interesting and informative, I suggest to The Test Eye to anybody who hasn’t heard of it already.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

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

I was looking for information about REST API (Representational State Transfer), I came across on this blog “How to design a REST API”. I found this blog to be useful, simple and has examples include. The blog and Quick Reference Card divided into 4 main sections.

First section is general concept, one of the main goals of API should be able to reach out to as many developers as possible. That mean API needs to be self-describing and simple. In security, how important is Oauth to manage Authorization, that being used by many companies. Which use the token system, without showing the real Authorization. API domain names are also important that need to be clear and straightforward.

Second is URIs, RESTful API use different approach using concrete names and not action verbs. API needs to have case consistency and plurals to make the structure clear. Versioning should be mandatory in the URL. Crud-like operations explain how HTTP Verb uses (GET, POST, PUT, DELETE) as CRUD action (READ, CREATE, UPDATE/CREATE, DELETE) with examples.

Third section is about query strings, combined API design such as filters, pagination, partial responses and sort to give query better result, also to optimize bandwidth. We can use a range query parameter. API response should contain Link, Content-Range, Accept-Range.

Finally, the Status Codes, developers will come across this. We need to return error for common case, which everybody understands. The HTTP return codes is which highly recommended for this. First case is success, which mean the API accepted the request. Second is client error, when client requests but API couldn’t accept, reasons such as 401 Unauthorized, 405 Method Not Allowed … There also Server Error, where the request is correct, but a problem occurred on the server. System will return as Status 500 Internal Server Error. This return is somewhat common, the client cannot do anything about that.

I like this summary of practices, its cover a large amount of good detailed references. The Quick Reference Card is clear and always have good examples next to it. I find that much easier to understand, since they use examples from popular sites such as Google, Facebook, Twitter. Everyone is familiar with those companies and based on the instruction, that make the examples are more reliable.

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

As I take another step towards my journey in software C.D.A. I dive into Software Architecture and its importance and benefits. For this weeks blog I found a blog named “15 BENEFITS OF SOFTWARE ARCHITECTURE” by  Ekaterina Novoseltseva. This blog talks about the benefits of software architecture. I will sum the main points of that blog and what I’ve learned from it.

What is something new I learned from this blog?

From reading the blog “15 benefit of software architecture” I have learned the 15 reason why having software architecture is important. I have also learned that not only its important in a sense it can be considered as the foundation for having a strong software program.

What is Software Architecture? 

The idea of software architecture is that it is considered to be the blueprint for building a software program. Usually the software architecture is the step where deciding what design would be implemented on the software and what each team member would be implementing to the program. “Architecture is an artifact for early analysis to make sure that a design approach will yield an acceptable system. Software architecture dictates technical standards, including software coding standards, tools, and platforms.” as stated by Ekaterina Novoseltseva blog.

The following are the 15 Benefits of Software Architecture:

1. “Solid foundation” – when creating a program or project having a solid foundation is part of the Software Architecture.
2. “Makes your platform scalable.”
3. “Increase performance of the platform”
4. “Reduces cost and avoids code duplicity”
5. “Implement a vision” – where a software architecture provides the big picture.
6. “Cost saving” – helps point out areas where money can be saved within a project.
7. “Code maintainability” – helps programmers be able to maintain the code within a project.
8. “Enable quicker changes” – able to change program at a fast past as what the program must do changes.
9. “Increase quality of the platform” – making the software quality incredibility better.
10. “Helps manage complexity”
11. “Makes the platform faster.
12. “Higher adaptability”
13. “Risk management” – helps reduce the risk or chances of failure.
14. “Reduces development time.”
15. “Prioritize conflicting goals”

The list above is the benefits to software architecture. Through the benefits we can see the importance of software architecture. Reading this blog has made me realize that software architecture is a very important step when developing a software system/program. This has been YessyMer in the World Of Computer Science, until next time. Thank you for your time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Nowadays, Unified Modeling Language has made it easier to describe the software systems, business systems, and any other systems. Their graphics show an explanation with words and pictures also, which proves that UML is practical and anybody should be able to use it. UML first appeared in 1997 and its content is controlled by the Object Management Group. The primary contributors to UML are Grady Booch, James Rumbaugh, and Ivor Jacobson.

UML Basic Notation

Why UML?

UML has been able to unify the terminology and different notations, which leads to a great communication between all parties, on different departments of any company. It is also much easier for co-workers to get access or transfer information, while they are working on the same project. UML seems to be a very powerful modeling language, which makes it perfect to use, even for small projects. Stereotypes can extend its functionality if it is not sufficient for some kind of projects. UML did not come from anywhere, it started from real-world problems with existing modeling language that needed modification or transformation. This is why it is widely supported because it guarantees usability and functionality, based on real-life problems.

UML 2.0 defines 13 different types of diagrams, where each of them may be expressed with different details. They are classified into three categories: Structural diagrams, The Behavioral Diagrams, and The Interaction Diagrams.

–          The Structural Diagrams represent elements that are static in nature and they can be fundamental to the UML modeling of a system. This contains:

The Class diagram, The Component diagram, The Composite Structure diagram, The Deployment diagram, The Object diagram, The Package diagram.

–          The Behavioral Diagrams represent the modeling of how the system functions. This contains:

Use Case Diagram, Activity Diagram, State Machine Diagram.

–          The Interaction Diagrams represent how the flow of data and control work on the modeling system. This contains:

Communication Diagram, Sequence Diagram, UML Timing Diagram, Interaction Overview Diagram,

As a conclusion, the Unified Modeling Language is an internationally accepted standard that is used for Object-Oriented Modeling and can be used to represent a model that adopts the best software architecture practices.

References:

https://commons.wikimedia.org/wiki/Unified_Modeling_Language

https://en.wikipedia.org/wiki/Unified_Modeling_Language

https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

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

http://blog.qatestlab.com/2011/03/01/difference-between-white-box-black-box-and-gray-box-testing/

          I found an interesting bog post this week that talked about the differences between White Box, Black Box, and Gray Box Testing. It started with black box testing by explaining that it is an approach where the tester has no access to the source code or any part of the internal software. The basic goal of this testing type is to make sure that inputs and outputs work from the point of view of a normal user. The blog goes on to talk about the main features of this testing type by explaining that the test design is based on the software specification and detects anything from GUI errors to control flow errors. It is a short prep test which helps make the whole process much faster but lacks the needed detail to test individual parts of the software. The blog goes on to talk about white box testing which allows the tester to have access to the source code. This testing allows the tester to know which line of code corresponds with which functionality. This allows more detail for individual tests on code functionality. It allows more detailed testing with the ability to anticipate potential problems but takes more time and can be complex/expensive. As for grey box testing, the blog explains that it is an approach where testers only have a partial understanding of the internal structure. The advantages and disadvantages of this technique are incorporated from the related white and black box testing.

       I chose this article because I remember that we learned about this subject in the beginning of the year. I wanted a better knowledge about the advantages and disadvantages which is what sparked my initial curiosity. I found that this content was really interesting because it explains how testing can be when dealing with different amounts of access to data. I enjoyed how the post explained the types of testing sequentially while also explain how they can be different from each other. I was able to grasp an understanding of these testing types while also understanding the importance and vital role that they play depending on the situation. The most interesting part of the blog post was the grey box testing because it combines the aspects of black and white box testing. It also deals with regression testing and matrix testing which are very important when testing code bits of code at a time. I found that the diagrams used in the post allowed an easier flow to the readings which helped me understand it better. I found the blog to be a great source that summarized and simplified the detailed ideas within the post.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Visitor Design Pattern

For this week’s blogpost I will be discussing another design pattern, this time I will talk about the Visitor Design Pattern discussed on Source Making’s website. Essentially the Visitor design pattern allows you to add methods to classes of different types without much altering to those classes. Allowing you to make completely different methods depending on the class used. Because of this you can also define external classes that can then extend other classes without majorly editing them.   Its primary focus is to abstract functionality that can be applied to an aggregate hierarchy of element objects. This promotes designing lightweight element classes due to the processing functionality being removed from the list of their responsibilities. New functionality can be added later easily by creating a new Visitor subclass. The implementation of Visitor beings when you create a visitor class hierarchy that defines a pure virtual visit() method in the abstract base class for each of the concrete derived classes in the aggregated node hierarchy. Form here each visit() method accepts a single argument – a pointer or reference to an original Element derived class. In short, each operation to be supported is modelled with a concrete derived class of the visitor hierarchy. Adding a single pure virtual accept() method to the base class of the Element hierarchy allows accept() to be defined to receive a single argument. The accept method also causes flow of control to find the correct Element subclasses, once a visit method is involved the flow of control is vectored to the correct Visitor subclass. The website listed below goes into much more detail into what exactly happens but here I summed it up so that most should be able to follow. But essentially the visitor pattern makes adding new operations easy, simply add a new Visitor derived class but if subclasses are not stable keeping everything in sync can be a bit of a struggle.

Example of Visitor Design Pattern

The example they use in the article is that based around the operation of a taxi company. When somebody calls a taxi company (literally accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi, the customer, or Visitor, is no longer in control of his or own transportation but the taxi driver is.

All in all, I thought this website was really good at explaining what the Visitor Design Pattern is. I have used this website before for previous research into design patterns and more.

https://sourcemaking.com/design_patterns/visitor

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