Welcome back to Dcanton’s blog. This week I’m going to be talking about  a blog posted on Apiumhub, a tech hub that specializes in software architecture. The blog talks about the benefits of unit testing. The author starts by giving the goal of unit testing which is to segregate each part of the program and test that the individual parts are working correctly. He then continues to list why it is beneficial. One of the benefits is that it improves the design of the program, it makes you think about if your code is well defined and if it reflects what the outcome is supposed to be. Another benefit of unit testing is that reduces cost long term, since bugs are found earlier in the process, they won’t be as costly and much easier to fix than later in the process.

I chose this blog to discuss this week because it has a lot of information on how effective unit testing is. Since there are other ways of test such as black box testing and grey box testing, this gave me a good understanding of it and the benefits that come from using this method. One thing I learned is that white box is tested by tester while others are tested by developers. Thank you, Dcanton blog will be back next week with another blog

https://apiumhub.com/tech-blog-barcelona/top-benefits-of-unit-testing/

From the blog CS@Worcester – Dcanton Blog by dcantonblog 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.

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC refers to whole process of software development. It defines and describes, each and every phase that contributed towards the development of the software.

What is the need for SDLC? Software Development is a tedious and complex job. As such, standard guidelines and established framework works well to carry out the development process in an effectively organized manner, repeatedly for each unique software product. Segregates the process of development life-cycle into separate phases, for their independent and smooth implementation. And to minimize failures in a software project. There are six phases of Software Development Life Cycle in a subsequent manner:

Requirement Gathering and Analysis: This phase visions the gathering of business requirements, followed by the analysis to study and validate the feasibility of these requirements for implementation in the system. Client and Project Manager are the key persons in this phase.

Design: blueprint/software design is prepared, based on inputs, provided from the requirement gathering and analysis phase. This blueprint helps in determining the requirements, needed in the development of software such as hardware and system requirements. The outcome of this phase is software design.

Implementation: The software design is implemented in this phase through coding and programming. This phase generally involves modules and codes. This phase is developed or working software product that acts as an input for the next stage.

Testing: developed software is handed over to the testing team, to evaluate and validate the functioning of the software product, in accordance with its pre-defined requirements and meet the end users’ expectations.

Deployment: After getting through testing phase, successfully, software product is ready to get deployed on customer’s side for its use

Maintenance: Maintenance phase is all about resolving defects or issues, occurring on the customer’s side, while using the software product. It ensures the fixing of all issues post the deployment of software product at the customer’s site.

This is the main steps of software review, it is a standard practice that empowers organizations to follow systematic & well-defined approach, for carrying out the development in an effective way, so as to achieve desired software product of highest quality. I find this blog helpful to follow and make sure product is going to the direction.  These steps need to apply to future product., as I have seen so many products got issues and have to call back.

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.

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.