Quality Software Design

Note: I don’t use Emojis in plain text, so I label my reactions a specific way
I denote it the following way as to give the reader a sense of my personal mental thoughts or reactions towards something. It’s kind of like an Emoji… Except its just boring text! [:laughing:]
Sub-note: Apologies for not updating for this class for a few classes. I’m working to get back on track!
We begin today by speaking of good software design. Lets talk about it.

Some qualities of good software design? One quality that well-made software have against poorly-made software is that it shows a large variety of functions and features related to its purpose. Another is the ability to add new features seamlessly. Java allows us to do this throughout its classes. These classes can interact with one another, have many variables and many different methods (or functions.)

Java is a well chosen example of a good software designer, as it allows for easy creation of objects and systems that work together to make one whole large system. It also allows for massive levels of modification and for addition or deletion of content on a whim. It is all up to the programmer!

There are also difficulties to come with the advancements seen in Java. One must learn of its many ins and outs to be able to successfully conjure up oneself a piece of beautiful software!

Lets say we have a player class, and it has methods that pertain to a player of a video game. Then, a character inherits or extends this class, but overrides unnecessary methods within the class. The player class is a interface if its subclass inherits from it, and if a subclass inherits from it, its an interface.

Otherwise, the player class is an abstract class. An abstract class has its subclass extend from it.

In the big picture (according to our professor Dr. Wursts slide) there are two main things to consider: the IS-A relations and the HAS-A relations. The person class is a class. The person class has a method/s and variable/s.

Mainly, today we have been talking a lot about the things we can do in a Java-based system. I know I haven’t been as detailed as my last few posts, but regardless, I hoped you enjoyed the read!
(goodness even the caffeine could not drive me to write well today! [:laughing:] )

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

Six Pitfalls In Testing

A recent blog post I read is entitled “Six Things That Go Wrong With Discussions About Testing”.  It is a post from August 27, 2017 on James Bach’s blog http://www.satisfice.com/blog/ .  In it James Bach talks about six big pitfalls that developers fall into when thinking about and talking about testing.  I chose this blog post because after reading it the information stuck with me.  He takes a step back from testing and writing tests and talks more about how to effectively test.  I thought it was a good topic that a lot of testers and developers overlook.  The first point is that people care too much about the number of test cases and losing focus on writing effective test cases.  This is a sound piece of advise to remember especially in college before getting too far into a career in software development; it’s more important to write a few strong tests than to write a lot of weak tests.  The second is that people treat a test as an object rather than an event.  This one interested me a lot.  It’s a good way to look at tests.  A test isn’t just an object, it is an activity and no test will be the same between two testers.  The third topic he talks about is when testers can’t describe their test strategy.  It’s a good reminder that as testers we need to constantly reevaluate our testing strategies and adjust it as necessary.  When we don’t step back and check ourselves we stop progressing.  The fourth point is that people talk about testing as if it is an automated process.  When we do that as testers it removes the human aspect of creating the tests.  This creates a division between testers and the tests.  We start to stop taking responsibility when a test doesn’t go right and that responsibility is important to have in order to learn from mistakes in testing and get better.  The fifth is when people talk as though there is only one kind of test coverage.  Even if a tester develops their own style and favors one type of test coverage during their career, it is important to remember that there are many kinds and a tester should keep them in the back of his mind so they can be ready to switch to the most effective kind depending on the situation.  The final pitfall is when people talk about testing as if it is static.  This is a fundamental concept that, in my opinion, should apply to almost all aspects in life.  When you think you are done improving then you are.  A good tester needs to always be open to new ideas and ways of doing things.  That mentality helps a tester to improve and avoid becoming stagnant. Which fits perfectly since thats the idea behind this assignment of blog posts.

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

Commenting

Source: http://blog.cleancoder.com/uncle-bob/2017/02/23/NecessaryComments.html

Recently, I read up on the blog cleancoder, by Robert C. Martin on Necessary Comments. The blog talks about how having a comment on every single piece of code that you wright is unnecessary. He says that when coding adding comments should be a last resort. He later even gives a good example of when this should be used. He was working with another member of his team for an improvement for their website. Whenever a customer purchases a video from their website it would then also find all the videos that had been purchased by others who had bought that video, and would pick the most popular and recommend it to the customer. They did not want the customer to wait forever for the suggestions so they decided to put the long running functions into another function that would return the previous result from the cache and if more than the N minute had passed, would run the algorithm in a separate thread, and cache the new result. They called this function the “choke function.” However, when they were testing it and trying to improve it when they tried to have other read the code most people would not know what they were trying to do so they kept going back to the diagram and that was wasting time. So, they decided to make a longer explanation of what the code did and they also drew in a diagram. Robert said “This doesn’t happen all the time.… But it does happen; and when it does nothing can be more helpful than a well written, well thought through, comment.”

I decided to read up on the blog because I was taught to have a comment on every line. This way it is clear on what I am doing and if I make a mistake it would be easier to find where in the code it is in. After reading this blog I can see why writing comments on every single function is useless because in the real world there are people who know what you are talking about. However, if you do decide to write a comment on a function make sure it is a well written, well thought out, comment. For myself I think I will still write comments on many of my functions however if it is very simple and easy to understand I will not waste my time writing it.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

The 5 Rules of UML

Today, I came across a blog called “UML Best Practice: 5 rules for better UML diagrams”. The blogger discusses their five rules for making better UML diagrams. The first rule; less is more. This approach helps to simplify the appearance of your diagram and helps to keep it looking neat and organized, therefore making it easier to understand. The second rule is to avoid crossings. This means to avoid intersecting your lines when establishing the relationships between classes. This goes hand in hand with the first point, as it helps to avoid a messy looking diagram. The third rule is orthogonality, which in short is using only vertical and horizontal lines to establish relationship; not using any diagonal lines. Rule number four is called “parents up” which is making sure that all parent classes are located above the child classes, so that all arrows point up, and it makes the UML diagram easier to read because it now has a natural flow. The fifth, and final, rule is simple; tidy up your work. Try to connect boxes using a single horizontal or vertical line, avoid turns in lines, and make everything uniform.

I chose this blog because I’m still learning the ways of UML, and I’ll take any tips to make it easier to draw/understand. I feel that the content, while not necessarily technical, is imperative to making and presenting good UML diagrams. Without organization, readers will get lost, lose attention, or just straight out ignore your diagram. For example, say you’re a developer. Part of being a developer is creating these UML diagrams to give to the coders so they can write your program. If your diagram is difficult to understand (intersecting lines, parent classes being located underneath the child classes, etc), the coders will have a hard time interpreting what you want done, and there’s a good chance that your program will turn out wrong. Your chances of getting a complete and correct program are much more likely if you make sure your UML diagram is clean and concise. Using these five rules will help to give your diagrams that edge, and it will create uniformity between all of your UML diagrams.

I like making things look clean cut and professional, and I hope that these five rules can help me make my UML diagrams look as good as they possibly can. I want to be able to interpret my UML diagrams with ease, and I want to be able to understand it without having to dissect every class and every branch. Following these five rules will help with this.

Here’s the link to the blog: https://geertbellekens.wordpress.com/2012/02/21/uml-best-practice-5-rules-for-better-uml-diagrams/

 

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Java Interfaces

http://tutorials.jenkov.com/java/interfaces.html

Jenkov’s article is about a core concept of java and other object-oriented programming languages; interfaces.  As basic as the concept is to programmers, it’s important to have a full understanding of such core concepts.  And that’s where I think this article excels.  It does a great job at making the information much more learn-able, digestible.  Far better than the oracle libraries, Jenkov explains how to implement and work with interfaces in projects.  His article does a good job of explaining what’s in the examples and code.  The first he speaks of, after what an interface is and how to implement it, is implementing multiple interfaces.  Unimpressive it may be, but it helped me. It’s not like the code was hard to learn or understand.  It’s just a huge help to how I learn to see everything completely explained.  Just looking at an example isn’t always helpful to me.  Although in the case of implementing multiple interfaces, it would have been.

 

Beyond just what we can do with interfaces and inheritance, he explains how interfaces relate and operate with core concepts in object-oriented programming.  Opting to discuss the usefulness of interfaces as well as how to implement them.  This portion of his work was most beneficial to me.  To not only know how to create interfaces but to also know how to use them effectively.  Paired with his explanations, he gives examples of good coding practices with interfaces.  But he doesn’t explain only what interfaces can do.  He also warns of the short comings of interfaces.

Sure, they are awesome examples of polymorphism in programming but, they can be broken.  One of the things to be cautious of is having overlapping method signatures.  Something I learned; Java classes can only implement a method with a given signature once.  Thus, having the same signature in two interfaces is a problem.  However, it shouldn’t be too much of a pain as long as the programmer remembers what they’ve already written.

Another great lesson I got from this writing was on how inheritance can work with interfaces.  I hadn’t known before that interfaces could inherit from one another and any class inheriting from a child interface got everything from the parent as well.  The article gave me a good overview on how interfaces work as well as ideas and understanding on how and when to use them.

 

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

Lambda expression in java

A Lambda Expression is a representation of an anonymous function which can be passed around as a parameter thus achieving behavior parameterization. A lambda consists of a list of parameters, a body, a return type and a list of exceptions which can be thrown. I.e. it is very much a function, just anonymous.

An instance of a lambda can be assigned to any functional interface 
 whose single abstract method’s definition matches the definition of the lambda. In fact, a lambda is a less verbose way of defining an instance of an interface provided the interface is functional. Since, the definition of a lambda can match the definition of multiple functional interfaces, hence, a lambda instance can be assigned to any of these matching interfaces.

The reason i picked this topic was because it was something new i have seen in the java language. Also wanted to know more about it and see if i can utilized it on some of my java programming language.

Examples of lambda expression.

First of all. Comparing java 7 to java 8.

public interface StateChangeListener {

public void onStateChange(State oldState, State newState);

}

In java 7 we implement this interface in order to listen for state changes. You do this

public class StateOwner {

public void addStateListener(StateChangeListener listener) { … }

}

But in java 8 you can add an event listener using a java lambda expression. like this.

StateOwner stateOwner = new StateOwner();

stateOwner.addStateListener(

(oldState, newState) -> System.out.println(“State changed”)

);

 

From this topic ( lambda expressions), i learned that previous java or java 7, if i wanted a block of code to be executed, we need to create an object and pass the object around. From Java 8, lambda expressions enable us to treat functionality as method argument and pass a block of code around. Lambda expressions in Java 8 are very powerful and therefore very compelling. For me, lambda expressions is way much better, convenient and very easy.

link to the resource : http://tutorials.jenkov.com/java/lambda-expressions.html



 


   



From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Post 2: The use of Strike Teams
			

								


				

			
I read a blog post by the people at Chaotic Good Programming and they talked about how they began to use Strike Teams at their work place. I’ve never heard of strike teams besides some fake ones in video games or something like that. The blog talks about the problems that bringing in Strike teams caused at first since bringing in new systems will always have some kinks in the beginning. The post says a strike team is “an idea that for projects that require expertise not found on any individual team, you pull in a person or two from multiple different teams to get all of the correct skills on a single team”. The idea is pretty interesting, lets say you’re working on a project and you need to put in physics into it and no one in your group is an expert on physics, you can grab someone from another group and put them on your team so you have a team with all the aspects to make your work the best it can be. There is problems though, they initially talk about cohesion when you pull someone which is true since if you’re not familiar with a person, then you might not be on the same page most of the time. Another problem was finding out who was gonna be involved on certain topic and when the end date was gonna be. Another problem was when was the start date gonna be, there are so many different teams that finding a start date to work with everyone was pretty difficult so they ended up doing a rolling start. Finally, the last problem they said was not to the strike team concept but to particular organization. They needed to construct meetings with people from across the country which was hard with the time constraints, so they left it to the IT of the place to re-arrange things to make it work. They finished by saying they are excited to see how this works out.


The reason I picked this blog post was because I found it as an interesting new concept that could be implemented at a future workplace that I’m at. The idea to me seems smart, get everyone on a team that can work on a task very well so they can get it done quick and the best it can be. It was also nice to see that this group was able to find solutions to each of the problems of the new system pretty quickly it seemed so they could get their projected off to a good start. I hope they post in the future on how this “Strike Team” system goes for them and their project and if they will continue to do this. I also wonder how it efficient it will be compared to their old system of doing things. I was able to learn what a strike team was by this post and how it works and some of the complications that come with it, I hope if I ever run into “Strike Teams” at future employers that they have been a thing for a while and are the best system it can be. Thank you for reading my blog post reflection on Chaotic Good Programming’s blog post on “Strike Teams”


Source: https://chaoticgoodprogramming.wordpress.com/2017/09/16/strike-teams/


   



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

		
		
	

							
	

				

			
						

				The Programming Language to End the Divide?
			

								


				

			
This article discusses how a startup company out the U.S. has created a programming language that solves the divide between the fast language of C++ and the functionality of Python. The company is called “Julia Computing”, which is the same name as the language they have created. The language is open source, meaning other startups and large organizations can feel safe to pick Julia as an option without having to worry about financial difficulties. In the wake of Julia, it has been picked up for testing and research by many large groups such as NASA and the Berkeley National Laboratory. It is also being used for aviation safety practices by using collision avoidance systems in aircraft.


I have selected this article because I am interested in the collaboration of new open source projects. It is interesting how computer scientists are striving to create multi-purpose language and return them as open source.  This project started in 2009 with a two people from MIT wanted to “simplify” the coding process. One of the developers of the language, Shah,  states, “The open source project was started to democratize programming, but to meet market demand for commercial products, we founded Julia Computing,”.


The first public version of the Julia language was actually released in 2012 and had over 100 open-source contributors to help move it along. I thought this was very interesting because it shows the motivation and effort that went into making a language that attempts to combine the strong suit of two of the most popular languages, C++ and Java. This idea of team collaboration resonated with me because many ideas can solutions can be brought to the table by multiple people, which can propel a project forward. I also learned that the Julia was used in the Celeste project in which it classified 188 million stars and galaxies in about 14 minutes and was run off of one of the 10 most powerful supercomputers in the world. I also learned that the process of creating product features for an open source language such as Julia is not as easy as it seems. “Keeping up with demand for new product features and packages is the biggest challenge, says Shah. “It takes anywhere from a few months to a year to create a product, and each product is continually improved to leverage the newest developments and improvements in the Julia open source language and to provide additional features requested by our customers and users.” This comment affected me in that although something may seem like an easy task, there are bound to be other issues that arise that can severely delay the development process. This is important to recognize because expecting the worst can sometimes help you see things that may have otherwise been overlooked.


Julia is consistently being optimized and could soon be efficient enough to challenge the industry giants that are Java and C++. Although Java and C++ are extremely dominant in the current era of computing,  with more testing, collaboration, and applications, Julia could find its way to become a programming titan.


Source: (https://www.forbes.com/sites/suparnadutt/2017/09/20/this-startup-created-a-new-programming-language-now-used-by-the-worlds-biggest-companies/#17581d2a7de2)


 


   



From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Could Robotics Process Automation (RPA) Be the Future of Testing?
			

								


				

			
According to blogger, Swapnil Bhukan, robotics process automation is indeed the future of software testing. In his blog post, Robotic Process Automation(RPA) evolution and it’s impact on Testing, he predicts that RPA will perform about “50 to 60% of testing tasks” by the year 2025. If you are not familiar with what RPA is, Bhukan also made a blog post describing what it is, how it works, and some of its benefits. Essentially RPA is a way to automate any repetitive task using bots that are taught how to do said tasks. Currently, according to Bhukan, RPA is only used to perform only about 4% of software testing tasks but that is sure to change as RPA technology advances. Today, the main use case for RPA has to deal with pretty basic data entry tasks.


The reason I chose to write about Bhakan’s blog post is because I found it quite interesting; especially since I was able to relate to the growth of RPA through past experience. Over the summer I had the opportunity to work an internship at an insurance company and all the IT interns had the pleasure of getting to sit down and talk with the EVP/Chief Innovation Technology Officer and ask him some questions. I asked him what kinds of new technologies the company was looking to invest in as well as what new technologies he was most excited about. His answer to both of these questions, requiring little time to think, was, hands down, RPA. Companies today are striving harder and harder to automate as many tasks as possible in order to save money.


One of the downsides to RPA, as Bhukan points out, is that it could potentially put many software testers out of a job. Some of the things keeping RPA form taking over the field of software testing at the moment are budgetary issues (RPA software is pretty expensive), companies being reluctant to adopt such new technology, and apprehension due to the possibility of losing customers if the tests aren’t done correctly. However, I believe that software testers may just have to realign their expertise as RPA technology evolves. By this I mean that the software testing professionals/developers should begin to learn how to teach these bots and leverage the bots’ usefulness in completing repetitive tasks; after all, the bots can only be as smart as those that teach them. I think Bhukan shares this view when he says at the end of his blog post, “sooner or later we (Software testing professionals) need to upgrade our skill set to train the Robots.”


 


September 24, 2017


-Caleb Pruitt


 


   



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

		
		
	

							
	

				

			
						

				WSU Blog #2 for CS-443
			

								


				

			






The Philosophy of Testing


This dense blog delves deeply into different types of testing and their uses. It outlines the philosophy behind software testing and explains the need for it. 


I chose this post mainly due to its sheer scope. This article covers a huge amount of content and I am confident that I will return to it often during our course. It first outlines a very different approach to the scientific method when applied to software development. The biggest understanding is that software testing is a two-way scientific method in that we design our test to verify the our code. When we discover problems, we will often adjust our code to satisfy the tests. This seems to contradict what we 


It provides a five point 


URL: http://www.codesimplicity.com/post/the-philosophy-of-testing/


 












CS@Worcester


CS-443







From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.