Author Archives: Ricky Phan CS Worcester

Software Architectural Patterns

Link to blog: https://medium.com/towards-data-science/software-architecture-patterns-98043af8028

In this blog by Anuradha Wickramarachchi, he highlights the different layers of software architecture. These include the Presentation Layer, Business Layer, Persistent layer, and Database Layer. He also describes that each of these layers contain several “components” such as open and closed layers. Each layer is described as follows:

Presentation Layer: The presentation layer presents and displays web pages,  UI forms and end user interacting API’s.

Business Layer: The business layer contain the logic behind the accessibility, security and authentication procedures. These include the Enterprise Service Buses, middle ware, and other request interceptors to perform validations.

Persistent Layer: The persistent layer is the presentation layer for data which includes the Data Access Object presentation (DAO), Object Relational Mappings (ORM), and other modes of data presentation in the application level. All of these types of data presentation reveals persistent data within the RAM.

Database Layer: The database layer provides simple databases expanding up to Storage Area Networks (SANs).

Components of these layers contain open and closed layers.  According to Wickramarachchi, open layers allow the systems to bypass layers and hit a layer below. This is done in critical systems where latency can cost a lot. At times, it is reasonable to bypass layers and directly seek data from the right layer. Within the closed layers, they reveal the concept of Layers of Isolation which separates each layer in a strict manner. This allows only a sequential pass through of layers without a bypassing procedure. Layers of Isolation enforces better decoupling of layers which makes the system more viable to changes.

I chose this blog because I wanted to know more about about Software Architectures and its layers. I knew briefly that within software architectures, they’d contain multiple layers that performed a number of tasks and jobs, and each layer differed from each other. One new thing that I learned from reading this blog was the Layers of Isolation. It was my first time seeing that terminology. I thought that it was interesting that the four layers of software architecture would contain other “components” in which Wickramarachchi explains as well as Opened and Closed layers.

I felt that Wickramarachchi was well explained and was very brief into the concepts I wanted to understand. He highlighted the main aspects of each layer without going overboard on extra content which helped understand the concepts further. Since I didn’t have a previous well understanding on software architectures, this blog clarified the fundamentals of software architectures that I wanted to understand.

 

 

 

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

Static vs. Dynamic Testing

Image result for static vs dynamic testing blog

http://www.360logica.com/blog/difference-between-static-testing-and-dynamic-testing/

Static testing and dynamic testing are two types of processes when testing software. Software testing is a process of analyzing and operating software to reveal bugs.  Static testing is a white box system of testing where developers check the code to find a fault. Dynamic testing is a process of operating a real application with valid entries to verify expected results.

Other main difference between the two types include:

  • Static testing is about prevention whereas dynamic testing is about cure.
  • Static testing is more cost-effective than dynamic testing.
  • Static testing tools provide greater marginal benefits as compare to dynamic testing.
  • Static testing gives comprehensive diagnostics for code than dynamic testing.
  • Dynamic testing finds fewer bugs as compare to static testing.
  • Dynamic testing usually takes longer time as compare to static testing as it test each case separately.
  • Static testing covers more areas than dynamic testing in shorter time.
  • Static testing is done before the code deployment whereas dynamic testing is after the code deployment.
  • Static testing is done in verification stage whereas dynamic testing is done in validation stage.
  • In static testing code is being examined without being executed whereas In dynamic testing, code is being executed and tested without necessarily being examined.

I chose this blog because I didn’t know anything about dynamic or static testing. I knew that software had to be tested, but I didn’t know there were two processes. Finding about these two processes made me think that one process probably works much better than the other depending on the type of software that is being created. If I were to make an assumption of what type of testing I would most likely use, it would be static testing because I am the type of person that often checks code to find faults. However, after briefly learning about these types, it would all matter on the type of application in the end that would determine which test process would be most efficient to find bugs. I also think that if I were to test software, I could use both because why not.

Overall, this blog outlined the most important aspects of static and dynamic testing. Understanding these two types is important because when I go and develop gaming software, there would be different types of games, which contain different code layers that I’d need to analyze and find bugs. A lot of games nowadays have updates and bug fixes, so it is necessary for me as a future game developer to find all the bugs or at most of them before releasing the game for the public to enjoy.

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

Elements That Cause Design Smells

http://www.codeops.tech/blog/linkedin/what-causes-design-smells/

In this blog presented by CodeOps, he explains what causes design smells. From the image displayed above, some of the causes include violation of design principles, inappropriate use of design patterns, language limitations, procedural thinking in OO (Object-Oriented Environment), viscosity, and non-adherence to best practices and processes. 

CodeOps gives an example for the violation of design principles by considering the Calendar class in java. He makes a valid point that the Calendar class that is part of the java.util package has a Multifaceted Abstraction Smell because the class itself is overloaded with multiple responsibilities and tasks, which violates the Single Responsibility Principle.

To provide an explanation of inappropriate use of design patterns, CodeOps explains that software designers sometimes apply methods that solve problems but often do not know the full understanding of the effects of their solutions. There needs to be a balance of design patterns, which is why designers need to know which patterns would be needed to efficiently implement the function of the software.

There are many kinds of programming languages out there such as C, C++, java, python, and perl. These languages can differ from one another in a sense that some generic features in these languages may not support certain primitive types. This is called language limitations because there are limits to what each programming language can do as CodeOps states for example “since the generics feature in java does not support primitive types, it is not possible to eliminate such code duplication when programming in java.”

Procedural thinking in OO refers to programmers implementing procedural thinking into their code. These programmers make the mistake of thinking that classes are “doing things” than “being things.”

Viscosity means resistance and is in the form of two types: Software Viscosity and Environment Viscosity. Software viscosity is the resistance that must be encountered when the correct solution is being applied to a problem. Environment viscosity is the resistance offered by the software development environment that must be overcome to develop good practices.

Non-adherence to best practices and processes can cause design smells because a process in a design that is not properly practiced or tested can definitely result in problems within the entirety of the software itself.

I chose this blog about design smells because I wanted to take into account what causes design smells. Part of what I learned about it was that you needed to right “clean code” and not “bad code” in order to have a high quality design. However, I had a feeling there was more to it than just writing a properly written code. Taking in all of these elements helped me understand how to avoid design smells. Elements such as these helped me understand how to work and process a design outside of the realm of programming.

 

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

Test Cases

https://blog.testlodge.com/types-of-test-cases-in-software-testing/

In this blog written by Jake Bartlett, he explains the different types of test cases and the importance of knowing the different types to discover which type to use for the right purpose. These types include functionality test cases, user interface test cases, performance test cases, integration test cases, usability test cases, database test cases, security test cases, and user acceptance test cases. 

Functionality test cases are used to discover if an application’s interface works with the rest of the systems and its users. It recognizes if the functions of the software succeeds or fails of what it is expected to do. User Interface test cases are used to confirm that specific pieces of the Graphical User Interface look and work. These test cases can also search for inconsistencies, spelling and grammar errors, and other elements the user interacts with. Performance test cases validate response time and overall effectiveness of an application. Integration test cases are meant to determine how different modules interact with each other. This test case guarantees that interfaces between different modules are working properly and effectively. Usability test cases help identify how a user approaches and uses an application. This test case guides the tester through situations and flows. Database test cases are used to verify if the developer has written code that stores and handles data in consistent safe manner. Security test cases help ensure the application restricts actions and permissions when it is necessary. These test cases main purpose is to protect data when and where it needs to protected. User Acceptance test cases help test the user acceptance testing environment. These test cases main purpose is to verify the application is acceptable to the user.

I chose this blog on test cases because it sparked my interest that there were different types of test cases. With my minimal prior knowledge about test cases, I though there would be at most four or five test cases, when there are in reality, eight test cases. That surprised me at first, but when I started to learn about the different situations of testing software, it made sense that it was necessary to have all these types of test cases to account for every situation.

Bartlett’s blog was very informative to me. He broke down each test and explain what each test’s purpose and goal was. As a software developer striving to become a video game programmer and developer, it is important for me to know these test cases because I’ll need to create effective applications that are well tested to run and execute a successful video game. If I don’t properly test my video game software or if I am unaware of which way to effectively test my software, my video game software is as good as a dead software with no purpose.

 

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

Software Design Patterns

https://airbrake.io/blog/design-patterns/software-design-patterns-guide

Design patterns provide guidelines for software developers to help deal with problems that could occur during their process in developing the software itself. In this blog written by Andrew Powell-Morse, he gives a brief overview about why design patterns are necessary in the world of software development and its origin.The origin of software design patterns can be extracted from the teachings of the book Design Patterns: Elements of Reusable Object-Oriented Software, which was published in 1995. The book explains object-oriented design techniques and different software design patterns, which are split into 3 categories: Creational, Structural, and Behavioral. 

Creational design patterns have several aspects that identifies that it is a creational design pattern such as abstract factory, builder, factory, prototype, and singleton. This type of design pattern emphasizes the automatic creation within code.

Structural design patterns have aspects such as adapter, bridge, composite, decorator, facade, flyweight, and proxy. This type of design pattern focuses on compositions of classes and objects.

Behavioral design patterns have aspects such as Chain of Responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template, and visitor. This type of design patterns focuses on the communication and assignment between objects.

I chose this blog because I wanted to know more of the basic overview in software design patterns. In today’s class lecture, the professor gave an example about how design patterns are useful with an example of a super class of ducks with sub-classes of different types of ducks and their behaviors. I was very interested in the example of ducks within the lecture, and after the lecture ended, I wanted to know a little bit more. I wondered if there were different design patterns and this blog led me to an answer that there were 3 categories of design.

Morse’s blog on design patterns was very informative and brief which was to my liking. It wasn’t too in depth because I only wanted to know a little more on the brief concepts of design patterns. This blog made me realize that there are many more design patterns out there in the world of software development. I’ve learned that the reason why there are so many design patterns out there is because those design patterns are meant to solve different problems that occur in many instances within the code during the process of developing the software. Considering that I do aspire to become a video game programmer and developer, I need to firmly grasp design patterns so when I go and create software for games, it’ll be easier for me to do so.

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

Introduction

Greetings CS-343!

My name is Richard Phan, but please feel free to call me “Ricky.” I feel that “Ricky” is a lot more friendlier and less serious. Like all of you, I am a CS Major who aspires in becoming a Video Game Developer. In order to reach that goal, I must learn and study software design, which this class embodies. I hope to have a wonderful semester with you all and develop a great experience in learning software design.

Thank you.

From the blog CS@Worcester – My Journey in Becoming a Video Game Developer by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Introduction CS-443-01

Greeting CS-443!

My name is Richard Phan, but you can informally call me “Ricky.” It’s a pleasure to be in this class with you all and I hope to have a wonderful learning experience in testing software!

From the blog CS@Worcester – My Journey in Becoming a Video Game Developer by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.