Hello, once again my fellow readers! I am sorry to report that this will be my last blog post for this semester and in turn this class. Continuing with my trend of Antipatterns today I will talk about a delicious Antipattern, Spaghetti Code.

SPaghetti code is the Antipattern that everyone first falls into when learning how to code a new language, learning a new coding tool, or learning how to code in general. Spaghetti code is the Antipattern representing code that has very little software structure. As a result, this leaves the code with a lack of clarity or direction, even to the original developer. This is the classic moment where you uncover code from some time ago, sit down, look at it, and go, “What was I even trying to do here?”

It can be quite easy to identify Spaghetti Code. Simply look for methods being very process oriented. Object implementation will also dictate flox execution. You will see minimal relationships between objects. You will see a very predictable pattern of object use.

Spaghetti Code can result in many consequences. Spaghetti code results in a program with diminishing returns. If Spaghetti code is mined, only part of the code will even be suitable for reusable if any of the code is reusable at all. As well, maintaining the code will result in being much more wasteful and a diminishing return as well. It will be more practical and less wasteful if a new solution is developed. Spaghetti code is so detrimental, it can even remove the benefits of object-oriented design.

To fix Spaghetti Code, you can refactor your code. Refactoring code is a natural and excellent way to maintain your code and is a wonderful way to increase performance. Code refactoring first must achieve a sufficient structure. Then, performance critical code must be identified and then structure compromises must be implemented as to enhance performance. Of course, the best way to get rid of Spaghetti Code is to prevent it in the first place.

As I was reading this, I knew that this is something that I could apply this almost immediately. In my next semester, I will have to work in a team and build off of an existing program. This Antipattern will stay with me and I definitely will see how I can work refactoring into the process to ensure that no Spaghetti code will remain. I have a sneaking suspicion that refactoring will be an idea that if implemented, will be able to squash many different Antipatterns that show up or are already lurking.

Well folks, this going to be my last blog entry for this semester. Thanks for reading and learning along with me (or watching me read). Until next time, have a wonderful day!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

In this blog, we are talking about test plan. Test plan is one such important testing deliverable offered during the release of the product. A software product, once developed and tested completely, is prepared for its release, during which various documents, reports, screenshots, etc. are also delivered to the client and other stakeholders of the project. Known as deliverables, these documents and reports are an integral part of software development life cycle (SDLC), in my last blog, as they necessary information related to the product to the concerned individual.

Test plan encompasses all the activities performed during the testing process. A test plan document offers all the necessary and relevant information to the developers, business managers, as well as the customers. There are different types of test plan:

• Level specific test plans: These include Unit test plan, Integration test plan and system test plan.
• Type specific test plan: these include plans for major parameters like performance testing plan.
• Master test plan: This is one single big plan combining all the other plans to be carried out on the software product.

Test Plan Template, the testing team or the test management team ensures that it follows a set template, which allows them to log all the necessary details about the testing process in the document. There are fixed set of parameters such as test items, testing approach, pass/fail criteria, approvals … there are all defined by the standard IEEE 829.

Creating a test plan by following guidelines, to make sure to create test plan accurately. It is important for them to consider few guidelines, which can assist them in recording all the necessary information in the document with precision. Create a concise test plan, with all the necessary information. The information provided should not be redundant and superfluous. While preparing a test plan it is necessary for the team members to be specific and precise. Create points, list, and tables wherever necessary, to increase the readability of the document. Review the document constantly before it is released with the product. Update the test plan with all the recent changes and modifications.
We know to make sure the test is in good quality, we need to know what we are looking for in testing. A testing plan would help us, a well written test plan ensures that all the aspects of the software are covered and tested. This combine with a check list would make further ensure the accuracy of out test.

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.

Hello, again my friendly neighboorhood readers!

This week I have been again been reading up on those crazy Antipatterns I discovered week. As you can probably tell by the title, the Antipattern I am writing about this week is a Halloween themed Antipattern. I know it’s a little late but today’s Antipattern is the Poltergeist.

A Poltergeist is a class that has a limited role to play or limited responsibilities in a system. This practice adds unnecessary abstraction and their short life cycle means more wasted resources. Poltergeists normally appear to initiate some other action of a class that has a more permanent status. A Poltergeist is easily identifiable as they will typically bear the “_manager” or “_controller” title in their name. The main three disastrous effects of the Poltergeist Antipattern is a waste of resources every time they are called, they utilize redundant navigation paths, and the clutter the object model, getting in the way of proper object-oriented design. If a Poltergeist Antipattern is left alone it can result in such occurrences as transient associations, stateless classes, redundant navigation paths, short duration, temporary classes, and objects, and single operation classes. Some typical causes that lead to a Poltergeist Antipattern manifesting are a lack of object-oriented architecture, using the incorrect tool for the job, and of course, a specific disaster such as management incompetence.

Now how do we fix this Poltergeist problem? Well, they gotta go. Of course, once the Poltergeists are gone, the functionality they had must be replaced with an adjustment to the architecture. Another solution is to utilize the 80% solution that we discussed in the post discussing the Blob Antipattern.

Now, I do not know about you reader, but I believe that this is definitely an Antipattern that every programmer falls prey too, especially when they are beginning. I can think of many programs that I have many over the years that have had at least one Poltergeist stalking around in them. This does make me rethink how I will program in the future. While the programs I may write now do not need any real optimization, in the future, optimization is going to be a required skill for me.

Well, that is it for today readers. Have a good week until next time!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

We learned about Model-View-Controller in class but there are more software architecture patterns, there are different layer is useful for different design. This blog is based on the book Software Architecture Patterns, by Mark Richards, Boston-based software architect who’s been more than 30 years about how data should flow through software. The author made top 5 software architecture patterns, which show how to choose them.

Layered (n-tier) architecture, this architecture arranged so the data enters the top layer and works its way down each layer until it reaches the bottom, which is usually a database. This is where the Model-View-Controller (MVC) structure, as we know, is the standard software development approach offered by most of the popular web frameworks, is clearly a layered architecture. Best use for: New applications that need to be built quickly, enterprise or business applications that need to mirror traditional IT departments and processes and applications requiring strict maintainability and testability standards.

Event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the type. This architecture is easily adaptable to complex, often chaotic environments, scale easily and easily extendable when new event types appear. This type of architecture best for asynchronous systems with asynchronous data flow, applications where the individual data blocks interact with only a few of the many modules.

Microkernel architecture, the basic routines for displaying a file and editing it are part of the microkernel. The solution is to push some basic tasks—like asking for a name or checking on payment—into the microkernel. Good use for this architecture is the applications with a clear division between basic routines and higher order rules and the applications with a fixed set of core routines and a dynamic set of rules that must be updated frequently.

Microservices architecture, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature. It’s used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. Best use for this is websites with small components, rapidly developing new businesses and web applications.

This is interesting architecture layers type, it is important to know and compare to real life application. I hope we more type to know more about the architecture, specially about website.

Link

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.

For my final blog for “Software Design and Architecture” this semester, I decided to research time management for doing software projects. This is an issue that I ran into creating my final project, and I thought it would be worthwhile to learn from my experience while it was fresh in my mind.

I thought this would be particularly helpful because I would like to do a few projects for fun over the winter break. I don’t think that I’m alone in that without a looming deadline, what little time management skills I have tend to go out the window. I hope this will change this time. I doubt reading an article will transform me into an extremely productive person, but at least it might point me in the right direction. I can only hope.

The article that I found was from *codeproject.com* and was titled “Time Management Tips for Developers.” I thought it gave some good pieces of advice. Even if you are not a software developer, you could benefit from all the advice given. I will focus on three pieces of advice that I would like to work on.

“Set your goals: long term and short term”: This is something that I know I should be doing, but I never do it in a methodical way. I make myself a goal, but never stick to it. I also never write it down, either. It is an incredibly lazy process. Which, funny enough is the next point.

“Do not plan in a lazy way”: Guilty as charged. I don’t put very much effort into planning. It’s no wonder I don’t stick to it. However, I have found it is sometimes hard to plan a project that I have never done anything quite like. Strangely enough, this thought was the topic of the next point.

“If you can’t plan, just track”: You should keep track of what you are able to get accomplished in a day and note where you waste your time. This seems like something incredibly useful for accurately gauging how your time is spent. It is too easy to either get discouraged or have false enthusiasm because you have either under- or overestimated how productive you were.

It seems like the author has some experience in doing projects like I am doing. It is really impressive that he can follow my thought process when reading one point and have the next point agree with what I was thinking in the next point. There were several other points that were good as well. I highly recommend checking it out.

Work Cited:

https://www.codeproject.com/Articles/11502/%2FArticles%2F11502%2FTime-Management-Tips-for-Developers

From the blog Sam Bryan by 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.