What is data flow testing? As we looked at path testing in class, data flow testing is one of the testing strategies, which focuses on the data variables and their values, used in the programming logic of the software product, by making use of the control flow graph. Data flow testing is the form of white box testing and structural type testing, which generally keeps check at the points, where the data values are being received by the variables, and at the points, when it is called for use. It is used to fill the gap between the path testing and branch testing.

Data flow testing keep in check of the coding errors and mistakes, which may result in to improper implementation and usage of the data variables or data values in the programming code. If all the data variables, present in the programming code have been initialized, or data variables which are put into use, have been, priory initialized, and if the initialized data variables, has been used, at least once, in the programming code. The data used in programming code, the life cycle goes through 3 phases:

• Definition: data variables are defined, created and initialized, along with the allocation of the memory to that particular data object.
• Usage: Declared data variables may be used in the programming code, in two forms
• Deletion or Kill: Memory allocated to the variables, gets freed and is put into for some other use.

2 types of Data Flow Testing: static data flow testing study and analysis of code is done without performing the actual execution of the code such as wrong header files or library files use or syntax error. And dynamic data flow testing, this involves the execution of the code, to monitor and observe the intermediate results. It basically, looks after the coverage of data flow properties.

The coverage of data flow in terms of “sub-paths” and “complete path” may be categorized under following types: all definition coverage all definition-c use coverage, all definition-p use coverage, all use coverage, and all definition use coverage.

This blog goes over basically all what we look at in class, although there not a lot of new information. There are more information on this website, specially about testing.

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.

We are looking at testing with Fakes, Mocks and Stubs. A Test Double is automated testing it is common to use objects that look and behave like their production equivalents but are simplified. This reduces complexity, allows to verify code independently from the rest of the system and sometimes it is even necessary to execute self-validating tests at all. The three implementation variations of testing doubles:

Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Fake implementation can come handy for prototyping and spikes. We can quickly implement and run our system with in-memory store, deferring decisions about database design. Another example can be also a fake payment system, that will always return successful payments.

Command Query Separation- Methods that return some result and do not change the state of the system, are called Query. It returns a value and is free of side effects. There is also another category of methods called Command. This is when a method performs some actions, that changes the system state, but we don’t expect any return value from it. For testing Query type methods we should prefer use of Stubs as we can verify method’s return value.

Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects. An object that needs to grab some data from the database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.

Mocks are objects that register calls they receive. In test assertion we can verify on Mocks that all expected actions were performed. We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change.

There are more test doubles such as dummy object, test spy. I thought this blog show clear each test and simple example.

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.

In our last week of blogging, (I know it’s sad) I decided that I will be continuing on a topic that was previously discussed a while back. (Two weeks because I procrastinated, but it’s okay we won’t talk about that). Today, or tonight rather, we will be discussing cyber security. I did my normal routine, and went back to my favorite website which I will post at the end of my last blog post for those who are interested. Anyways, the article is titled Proactive Approach to Defending Computer Systems. I saw the word proactive, and I jumped right into the article.

The article is about how three different research teams (U.S. Army Research Laboratory, the University of Canterbury in New Zealand and the Gwangju Institute of Science and Technology in the Republic of Korea) came together to take a step in the right direction in the field of cyber security. According to scientists, which who are not mentioned for some odd reason, this is a demanding research topic.

The article then talks about the threat of cyber attacks like most articles that talk about cyber security do. In fact, the beginning of this article is more or less just an introduction on cyber attacks and how they work, but we won’t discuss this because we all know what cyber attacks involve, or at least I think we do, and this is my blog so I’m moving on.

The real information comes in about halfway through the article. A new method was found, and it is known as Moving Target Defense, or MTD.

“The concept of MTD has been introduced with the aim of increasing the adversary’s confusion or uncertainty by dynamically changing the attack surface, which consists of the reachable and exploitable vulnerabilities,” Cho said. “MTD can lead to making the adversary’s intelligence gained from previous monitoring no longer useful and accordingly results in poor attack decisions.” (Disclaimer: this quote was in the article, and I didn’t want to take credit for a direct quote). This explains the concept of MTD and the rest of the article talks about how it is used to prevent information from being taken by attackers. To summarize, use a bunch of fake changing IP addresses to prevent the attack.

I didn’t enjoy this article as much as I thought I was going to, but I do like the concept of it is hard to hit a moving target, so lets keep changing the fake IP address so hackers can’t do anything. I think that this is definitely a huge advancement in terms of cyber security, and hopefully it can prevent a lot of attacks. If i had to change one thing about the article, it would be the half page introduction on cyber security, but I don’t write articles so they can do whatever they want.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The Adapter pattern is easy to understand as the real world is full of adapters. The general idea of an adapter in software development is identical to the one in the physical world. If you have been to different countries, you probably recognized that a lot of them are using differently shaped power sockets. Quite often, they are shaped in a way that the plug of your electrical device doesn’t fit. So, how do you connect the charger of your mobile phone or laptop to these power sockets?

The answer is simple. You get an adapter which you can put into the power socket and then you put your plug into the other end of the adapter. The adapter changes the form of your plug so that you can use it with the power socket. In that example and in most other situations, the adapter doesn’t provide any additional functionality. It just enables you to connect your plug to the power socket. The Adapter Pattern applies the same idea to object-oriented programming by introducing an additional adapter class between an interface and an existing class. The adapter class implements the expected interface and keeps a reference to an object of the class you want to reuse. The methods defined by the interface call one or more methods on the referenced object and return a value of the expected type. By doing that, the adapter class fulfills the expected contract by implementing the interface and enables you to reuse existing, incompatible implementations.

The Adapter Pattern is an often-used pattern in object-oriented programming languages. Similar to adapters in the physical world, you implement a class that bridges the gap between an expected interface and an existing class. That enables you to reuse an existing class that doesn’t implement a required interface and to use the functionality of multiple classes, that would otherwise be incompatible.

One advantage of the Adapter Pattern is that you don’t need to change the existing class or interface. By introducing a new class, which acts as an adapter between the interface and the class, you avoid any changes to the existing code. That limits the scope of your changes to your software component and avoids any changes and side-effects in other components or applications.

Thank you for reading!

Reference

https://dzone.com/articles/adapter-design-pattern-in-java

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.

The Singleton pattern encapsulates a shared resource within a single unique class instance. This instance arbitrates access to the resource and storage-related state information. A class method provides the reference to this instance, so there is no need to pass the reference around Any object that has access to the Singleton’s class header can use the Singleton.

This design pattern defines the structure of a class that can have only one instance. A Singleton encapsulates a unique resource and makes it readily available throughout the application. The resource might be hardware, a network service, a persistent store, or anything else that can be modeled as a unique object or service. Singletons may often be modeled as a server within the application that accepts requests to send, store, or retrieve data and configure the resource state.

Implementation

Implementation of the Singleton pattern often typically creates a single object using the factory method, and this instance/object is called a shared instance in most cases. Since the access to the instance is passed on though a class method, the need to create an object is eliminated.

Pros and Cons

Singletons are not the answer to every problem. Like any tool, they can be short in supply or can be overused. Some developers are critical of Singletons for various reasons. We will examine this critique and discuss ways to address them briefly. The criticisms, for the most part, fall into two categories:

Singletons hinder unit testing: A Singleton might cause issues for writing testable code if the object and the methods associated with it are so tightly coupled that it becomes impossible to test without writing a fully-functional class dedicated to the Singleton.

Singletons create hidden dependencies: As the Singleton is readily available throughout the code base, it can be overused. Moreover, since its reference is not completely transparent while passing to different methods, it becomes difficult to track.

To avoid these complications, when considering the Singleton pattern, you should make certain that the class is a Singleton. Also, while thinking of designing the Singleton design pattern, keep testing in mind and use dependency injection whenever possible, which means: try to pass the singleton as a parameter to the initializer whenever possible.

Thank you for reading, please share it if you found it useful!

Reference

https://www.geeksforgeeks.org/singleton-design-pattern-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.

We’re computer science seniors at Worcester State University so that means we should be able to write a full fledged technical documentation for the program we have written am I correct? Yes and no. We were taught the importance of writing documentation and very lightly touched upon what should be included in documentation but after reading ‘Software Documentation Types and Best Practices’ I learned there are actually different types of documentations for different projects.

The image below shows a general guideline for the steps to be taken when it comes to writing a project documentation.

We know that the main goal of effective documentation is to ensure that developers and stakeholders are headed in the same direction to accomplish the objectives of the project. The image below is a breakdown of the two main categories of software documentation:

The author then goes on and describes the different types of documentation:

System documentation represents documents that describe the system itself and its parts. It includes requirements documents, design decisions, architecture descriptions, program source code, and help guides.

User documentation covers manuals that are mainly prepared for end-users of the product and system administrators. User documentation includes tutorials, user guides, troubleshooting manuals, installation, and reference manuals.

Process documentation represents all documents produced during development and maintenance that describe… well, process. The common examples of process-related documents are standards, project documentation, such as project plans, test schedules, reports, meeting notes, or even business correspondence.

All in all I learned that there is not one special or main way to write documentation but there are actually many.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

After finishing our final project I was still curious on many things about angular and how we would use it in future projects if we were to transition over to becoming a front end developer. This blog ‘Why should you learn Angular in 2018?’ by Aman Goel talks about Angular is, the different types, and the advantages.

From what I’ve learned, Angular is a framework that developers use to build applications (a simplified view). Goel talks about the development of angular applications and how it incorporates Typescript along with HTML and CSS. I know I built my project with the latest version of angular when I created it with the @angular-cli/@latest command but apparently there are versions from Angular 1 to Angular 7 and skipping Angular 3.

Some advantages of using Angular is that it supports Single Page Applications which is what we did for our project. A single HTML page that is updated dynamically according to the interaction of the user.

He lists the advantages of using Angular as seen down below:

– Supports Single Page Applications
– Two-way data binding
– Modularity in Angular
– Reduced coding
– Declarative User Interface
– Easy Integration
– Cross Platform

Before reading this blog I did not know how much we learned from doing this project but after reading it, I realized that all of the advantages listed in this blog were used in the process.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Motivation:

Sometimes we need the ability to control the access to an object. For example, if we need to use only a few methods of some costly objects we’ll initialize those objects when we need them entirely. Until that point, we can use some light objects exposing the same interface as the heavy objects. These light objects are called proxies and they will instantiate those heavy objects when they are really need and by then we’ll use some light objects instead.

This ability to control the access to an object can be required for a variety of reasons: controlling when a costly object needs to be instantiated and initialized, giving different access rights to an object, as well as providing a sophisticated means of accessing and referencing objects running in other processes, on other machines.

Consider for example an image viewer program. An image viewer program must be able to list and display high resolution photo objects that are in a folder, but how often do someone open a folder and view all the images inside. Sometimes you will be looking for a particular photo, sometimes you will only want to see an image name. The image viewer must be able to list all photo objects, but the photo objects must not be loaded into memory until they are required to be rendered.

Intent:

The intent of this pattern is to provide a placeholder for an object to control references to it.

Implementation:

The participants classes in the proxy pattern are:

Subject – Interface implemented by the realSubject and representing its services. The interface must be implemented by the proxy as well so that the proxy can be used in any location where the RealSubject can be used.

Proxy – Maintains a reference that allows the Proxy to access the RealSubject. Implements the same interface implemented by the RealSubject so that the Proxy can be substituted for the RealSubject. Controls access to the RealSubject and may be responsible for its creation and deletion. Other responsibilities depend on the kind of proxy.

RealSubject – the real object that the proxy represents.

Applicability:

The Proxy design pattern is applicable when there is a need to control access to an Object, as well as when there is a need for a sophisticated reference to an Object. Common Situations where the proxy pattern is applicable are:

Virtual Proxies: delaying the creation and initialization of expensive objects until needed, where the objects are created on demand.

Remote Proxies: providing a local representation for an object that is in a different address space. A common example is Java RMI stub objects. The stub object acts as a proxy where invoking methods on the stub would cause the stub to communicate and invoke methods on a remote object found on a different machine.

Protection Proxies: where a proxy controls access to RealSubject methods, by giving access to some objects while denying access to others.

Smart References: providing a sophisticated access to certain objects such as tracking the number of references to an object and denying access if a certain number is reached, as well as loading an object from database into memory on demand.

Related Patterns:

Adapter design Pattern – The adapter implements a different interface to the object it adapts where a proxy implements the same interface as its subject.

Decorator design Pattern – A decorator implementation can be the same as the proxy however a decorator adds responsibilities to an object while a proxy controls access to it.

Reference

https://javapapers.com/design-patterns/proxy-design-pattern/

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.

As you may know, for our end of semester senior project we worked in groups of two in charge of developing a web application that had some sort of functionality. When we were first introduced to this we didn’t know whether to feel scared, nervous, excited or all of the above. What is HTML, CSS, angular, boostrap, etc.? So many things were thrown at us but in the end we made it. We learned all of it and no the question is.. are we full-stack devs? Maybe Eric An can answer that question in his article, ‘What is a full-stack web developer?’

The article begins with a big red T shaped image. The T-shaped model is a concept that describes the abilities/characteristics of an individual where a person has many generalized skills with a specialization in few. The full-stack web developer supposedly knows many technologies but specializes in few which is front-end development and back-end development.

Front-End web development is the presentation of the website which includes HTML and CSS and sometimes JavaScript; pretty much everything that the user sees when clicking a link. The goal is for users to provide a platform for users to interact with. Some other skills may be UE/UI design. For our project we learned the basics of HTML and CSS and I also learned how to use bootstrap to make things much simpler. Front-end development was a success!

Onto the back-end web development.. The creation of data collection processes haunts us to this day. We redefined the definition of struggle when it came to the back-end part of this project. Back-end development is associated with the front-end where as a server is being created to communicate with that the user is trying to do on the front end.

The definition of a Full-stack web developer is an individual who is in charge of performing both front-end and back-end so that all of the technologies put together makes up a website. After reading this article, although we are not experts in front-end/back-end development we could be considered full-stack developers!

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.