This week I will be looking at the decorator design pattern. This post discusses the advantages of using a decorator design pattern over inheritance in Java and gives examples of its implementation. The main advantage being a significantly less number of classes are needed when adding functionality using a decorator versus using traditional inheritance. It also mentions that the decorator should be added so that it is natively supported by programming languages. I think that this is the most interesting part of the entire article. I agree that languages, and in particular Java should start natively adding support for these design patterns. By doing this, as the article says it makes it much easier for beginner programmers to implement. I agree with this and I find that this can be challenging when you are first learning about design patterns and especially if you are starting out programming. In addition, I agree that a native implementation makes this design pattern, and others much cleaner to implement. As the example of the implementation in this article shows it would require a lot less work and code if it was implemented as they have it with just having a decorates statements instead of implements when creating a new class. I find this approach would encourage me and others to use this as it would be easy to use and not require repetitive typing, which as the article states would lead to better programs. I think this point of native support should also go beyond just this particular design pattern. I think that Java and other object-oriented languages should add native support for some of the other popular design patterns as well such as strategy or singleton. This would make it easier to experiment with different patterns earlier in the stages of learning to program and would let people see the benefits without struggling on the implementation necessarily. I would have found it much more encouraging to use one of these patterns as the article suggests if it was natively supported versus creating my own implementation based on text-book examples. Overall this article and what I’ve learned in this class have taught me to prefer using a design pattern over basic inheritance in most scenarios when building programs and that adding native support for these patterns would make it even better to use.

Source: https://dzone.com/articles/is-inheritance-dead

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Derek Banas has a youtube channel dedicated to java tutorials and higher level software development concepts. In his video series of design patterns, he describes the value and how to use the Decorator Design Pattern. Banas begins his tutorial by explaining the utilization of the decorator pattern, and then applies it by using a simple example based on a pizza making simulator.

The purpose and value of using the decorator pattern according to Banas is it allows you to dynamically modify an object, without having to hard code additional features. By extension, this allows us to add to old code without having to rewrite the program. Banas suggests to use the decorator pattern in situations where we would want to use inheritance, but where the classes need to be flexible enough to add features to during run time, so inheritance itself is not sufficient. By applying this pattern we are able to favor composition over inheritance.

Banas applies this pattern in an example of a program used to add toppings to a pizza, and display a description and cost. He first implements the solution to this problem using inheritance, hard coding each type of pizza subclass with a preset description and price. However, Banas notes how by using inheritance, we would have to implement an infinite amount of subclasses for each combination of topping. Furthermore, the change in price of a topping would necessitate changing every subclass using that topping. So regular inheritance is not sufficient for this program.

From here out Banas implements the decorator pattern using a Pizza interface, a ToppingDecorator abstract class with a Pizza instance variable, and PlainPizza concrete class. By creating topping classes that extend ToppingDecorator, he is able to add toppings dynamically to a PlainPizza object, calling a string of constructors for each topping (Pizza myPizza = new TomatoSauce(new Mozzarella)…).

I highly recommend Derek Banas’ youtube channel, as he is adept at breaking down high level software design strategies into simple examples anybody can understand, and he is skilled at illuminating the benefits of design patterns over more basic, intuitive implementations. The structure of his videos are easy to follow as well, starting with a high level discussion, moving down to a UML diagram, and finally implementing the solution. This strategy is very helpful for anyone learning or needing clarification on design patterns.

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

For this week, I have decided to read “Black box, grey box, white box testing: what differences?” from the NBS System blog. The reason I have chosen to read about this is because while I do understand the basics of what each box does, I have the need to find out more about the benefits and the perspectives of using them. I believe this will help in understanding the purposes of utilizing each one and why do some tend to use them for a certain amount of time.

This blog basically goes over as the title implies what do the boxes do and what do they offer for possibilities. Black box consists of reviewing only the functionalities of an application or rather what it does it is what is supposed to, no matter how it does it. The user needs to know what the role of the system is and its functionalities but does not need to know its inner mechanisms. For white box, it consists in reviewing the functioning of an application and its internal structure. All of the internal components of the software or application are tested through the source code, which is the main work base of the user. Grey box testing complies both of the previous approaches: testing both of the functionalities and functioning of a website. This means that a tester gives an input to the system, checks to see if the result is the expected one, and checks through which process the result was obtained from. It is vital with these kind of tests to make sure the product is complete, secure and efficient.

What I think is useful about this blog is that it provides the benefits and drawbacks for each box like for black box, it has simplicity and redundancy listed down and gives an explanation based on it. There is also the example of penetration testing to give an understanding of each box in a real-life situation. From this blog, it goes from the general definition to the boxes, explaining how the boxes works from one perspective to the next, benefits and drawbacks of the boxes, and finally a penetrating testing example.

Based on the content of this blog, I would say that this blog is a good introduction to knowing the boxes in concept.  I do not disagree with this content since it does try to give readers the information needed and provide great examples to get a clear understanding overall. For future practice, I shall try to get familiar with the examples the blog uses for the boxes in real-life situations.

Link to the blog: https://www.nbs-system.com/en/blog/black-box-grey-box-white-box-testing-what-differences/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

For this week’s blogpost I will be looking at yet another design pattern called the Prototype Design Pattern. Creating objects can take a lot of time and can be an expensive affair so in order to save time and money we can dive into cloning to solve this problem. You would want to use this pattern when the cost of the object to complex or expensive. After all, the clones in Star Wars were made to be cheap and expendable ultimately, the same goes for the idea behind the cloning pattern. Trying to keep the number of classes at a minimum is also a great time to use this object. Another big reason to use this pattern is when the client is creating objects that are required which are very similar to already existing objects, hence cloning. Essentially what this pattern allows you to do is make new instances by creating copies of existing instances. The result is a cloned object which is different from the original object, causing the state of the original to be the same as the clone right after the time of cloning. Therefore each object may undergo some state change, modifying the objects to perform different things after this is easily done. The structure of this pattern comes when the prototype class declares an interface for cloning itself by implementing the clone able interface and using the clone() method. Concrete Prototype then implements the clone method for cloning itself. After this the client class creates a new object asking the prototype to clone itself rather than using a new keyword. You need to instantiate the original class A(the class you are cloning) before using it. Then the client requests the prototype class for a new object of the same type as class A. This patterns great for scenarios where multiple profiles need to be created. In turn we can store the data in a single call and cache it in the session for further processing. Another more prominent example of cloning would perhaps be in the form of a bank account. Where you would want to make a copy of the object that holds your account information, perform transactions on it and then replace the original object with a modified one (a clone). The blog then goes on to list some more interesting points of the design pattern as well as some benefits and drawbacks. One of the drawbacks of the pattern is that classes with circular references to other classes cannot really be cloned. But a benefit of this pattern is that client can reduce subclassing with this immensely. All and all this pattern seems like something I would use actually quite often.

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

Software developer John Sonmez writing for simpleprogrammer.com gives a narrative of his experience as a lead developer, and how he applied the practices of test driven development and unit testing in his article What is TDD? What is Unit Testing?.  Sonmez stresses the definitions in these concepts and illustrates how they are applied in the development process.

Somnez begins by asserting that the purpose of a unit test is to verify the functionality of the smallest possible unit of code, usually on the class level. The author calls unit tests an “absolute specification”, and he explains that the value of a unit test is verifying that the smallest possible units of code function properly in isolation.

According to the author, by making sure unit tests are absolute specifications on the smallest possible units of code, unit testing can highlight problems in the design. Sonmez backs up his claim by describing how unit tests help developers discover tight coupling, and issues with cohesiveness, as the process of testing classes in isolation highlights these issues, since most programs have complex dependencies.

Sonmez moves on to define test driven development as the opposite of the traditional waterfall methodology of testing, where complete specifications were provided up front and tests happened at the end of development of a component. In test driven development, tests are written before any implementation, and only minimal code is written to make that particular test pass. After the tests pass, the developer refactors the code. This process Sonmez describes as “Red, Green, Refactor”, alluding to the red/green color of the unit tests.

The value of test driven development according to Sonmez is that tests are the best form of specifications, they either pass or fail; there is no room for interpreting the specifications. Furthermore, the author asserts that this development style is important because it forces the developer to understand the function of the code before implementing it. If we can’t describe exactly what the test should verify, then we need to go back and understand more, helping prevent errors before they happen.

I enjoyed this article and highly recommend it to anyone confused about how these concepts apply in the industry, as you can tell Sonmez’s professional experience has enlightened him in these areas. He is very good at simply describing concepts and the practical situations and uses of applying them.

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

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

https://testfort.com/blog/iot-testing-types-best-practices-through-reliable-testing-strategies

This blog post is about testing types and best practices for IoT devices. The market for these devices is growing at a fast rate and is continually changing. However, IoT testing is difficult because it requires a large base of physical equipment and knowledge about smart devices, IoT systems, and IoT test environments. Proven IoT testing approaches include compatability, security, beta, usability, and performance testing types.

Compatibility Testing

Compatibility testing should be a priority because IoT applications are run on innovative types of devices. This type of testing is necessary to protect software from vulnerabilities and system failures. An IoT testing team should have a well-equipped testing laboratory or take advantage of cloud environments.

Security Testing

It is important to test the security of IoT applications. There are three levels of testing:

• IoT device testing – makes sure that devices are protected from breaches related to APIs, authentication, updates, and setting configurations
• Network testing – protects the application from attacks on the network layer
• System testing – ensures that user data is protected from leakage and hacking

Usability Testing

Usability testing ensures that software is easy to use and intuitive. IoT testers need to make sure that an application is perceptive and configurable.

Performance Testing

Performance testing is used to test an application’s speed within an environment with large data loads. Testers can use cloud platforms to simulate large loads and generate non-standard scenarios to see how an application performs.

Beta Testing

Beta testing involves the development of realistic scenarios for IoT testing. Discovering failures and usability issues during beta testing helps increase the chances of a successful product release.

Overall I thought this blog post was interesting as I have never really thought about the special considerations for testing IoT applications. While I think this post did a good job explaining why testing IoT software is difficult, it could have benefited from being more specific. The author does not go into much detail as to how these testing strategies are uniquely used by IoT software. It serves more as a general overview for the goals of these testing methods. Regardless, after reading this blog I am interested in learning more about IoT software development and testing.

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

When I was reading about REST APIs, the acronym SOAP kept coming up. In this blog post, I wanted to learn more about what SOAP means and how it compares to what I’ve already learned about REST. The article that I am pulling information from, https://smartbear.com/blog/test-and-monitor/understanding-soap-and-rest-basics/, is a thorough resource, detailing features of each service and how each can be considered “better” than the other.

SOAP (Simple Object Access Protocol) uses XML, a language like HTML, to send requests to a server and receive responses. SOAP was designed to be extensible, with multiple acronyms coming with it to support different usages of the services, such as “WS-Security” or “WS-Coordination.” However, when using free, public web services, these extensions may not be necessary to come into play; it is simply convenient to provide extra functions if needed.

One potentially problematic feature of using SOAP has to do with the entry of XML for requests. Because the complexity of XML code to make requests, some programming languages have built-in support to handle such requests. However, some are not as forgiving and require manual building of the XML code. While SOAP has error handling (which helps to identify where the request went wrong, as well as potentially automate fixing such errors using standardized codes), it is still intolerant to errors caused from incorrectly building the XML. REST has more of an advantage here, because of its reduced difficulty when creating requests; instead of having to program an entire XML file (depending on whichever language you use), REST just uses requests through the URL. This results in faster performance with REST.

With this in mind, though, SOAP does provide other advantages. Coming with built-in error handling is certainly a leg up from REST, along with flexibility of services with other extensions that have different functions. While REST focuses more on quick performance and a lack of complexity, SOAP increases functionality and handles errors effectively.

It is also important to note that unless a developer is making their own Web service, most free and public Web services make it clear which access protocol they use, whether it is SOAP or REST. Even if the Web Service that I access for my final project already has a defined access protocol (which is REST), I am glad to understand more about other options out there for different services available.

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.