From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Link to blog: http://blog.architexa.com/2010/04/determining-which-uml-diagram-to-use/

This blog gives an overview on choosing which type of UML diagram to use when it comes to designing software. Some software designers may encounter a problem where they’re coming to a choice on whether which UML diagram to use that is most efficient for a particular task given to them. I am one of those designers because sometimes, I come to a problem where I can’t decide on which UML diagram I should use.

First, there are 3 classifications of UML diagrams: Behavior diagrams, Interaction diagrams, and Structure diagrams.

Behavior Diagrams: 

These are types of diagrams that show behavioral features of a system. This includes activity, state machine, and use case diagrams. Examples of a behavior diagram would be an Activity Diagram and a Use Case Diagram. The activity diagram shows high-level business processes, including data flow, or to model the logic within the system. To simply put it, behavior diagrams, in general, breaks down processes into individual decisions, loops and chain of events.

Interaction Diagrams: 

Interaction Diagrams are a subset of diagrams which emphasize the interaction of objects. This includes communication, interaction overview, sequence, and timing diagrams. These diagrams fulfill the need of designing a system where there are complex relationships between code elements and provides a view on how the elements interact over time. Examples of interaction diagrams include Collaboration/Communication Diagram, Sequence Diagram, Interaction Diagram, and Time Diagram. 

Structure Diagrams:

Structure Diagrams show elements of a specification that are irrespective of time. This means that the elements are not affected by the nature of time. Examples of structure diagrams include Class Diagrams, Composite Structure Diagrams, Component Diagrams, Deployment Diagrams, Object Diagrams, and Package Diagrams. Structure Diagrams, in short, help break large projects or features into parts and specify which parts do what and how they interact within the system.

I chose this blog because I wanted to know the different types of diagrams within the three classifications of UML diagrams. I was aware of the three classifications of UML diagrams, but I didn’t know certain types within each classification such as the Deployment and Composite Diagrams within the Structure Diagram Classification. The author of the blog briefly highlighted each of the three classifications in detail with links pertaining to each of the example diagrams presented within each classification. This made it easier to understand how each example operated. It is important for me to understand the different classifications and their examples of diagrams because when it comes to programming video games, which would be my future career, I would have to implement and figure which diagram is necessary for each type of game design.

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.

This week i read the blog few hiccups by Michael Bolton which can be found here. This article is about better describing the expectations you have for your code before testing which makes it easier to find problems in the code. Also in the article is identifying and applying oracles. I could not figure out what that meant at first but in an older Michael Bolton article i found the definition to be as follows.An oracle is a principle or mechanism by which we can tell if the software is working according to someone’s criteria; an oracle provides a right answer—according to somebody. That article which is called Testing without a map can be found here.

The article is actually a mnemonic in which the blog is based around. The mnemonic is split into two parts, FEW and HICCUPS. The HICCUPS part of the mnemonic refers to a list of  the authors oracle principles. HICCUPS is designed as follows:

• History. We expect the present version of the system to be consistent with past versions of it.
• Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
• Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
• Claims. We expect the system to be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals, whiteboard sketches…) or in conversation (meetings, public announcements, lunchroom conversations…).
• Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
• Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
• Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
• Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.

Each one of these is a criteria that can be used to identify a problem in your code. We have a problem once we realize that the product or system is inconsistent with one or more of these principles. The FEW part of the mnemonic is defined as follows:

Explainability. We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.

World. We expect the product to be consistent with things that we know about or can observe in the world.

Familiarity. We expect the system to be inconsistent with patterns of familiar problems.

These last 3 oracle specifications were added later on updating the mnemonic from HICCUPS to FEW HICCUPS. The way to remember this given in the article is: When we’re testing, actively seeking problems in a product, it’s because we desire… FEW HICCUPPS.

I stumbled on to this blog by accident while looking at other blogs about testing consistency but i am glad that i did. This was a very interesting read and was not like other blogs that i have read. All the different specification oracles in the article were interesting and each seems to have it’s place. These specifications i think would make you a much more consistent tester by giving you a consistent guideline for finding problems in your code. The mnemonic was my favorite part of the article and not something that i have seen to many times in software testing. This seems like it would be very helpful in memorizing these oracle principles well into the future.This is something i am going to try and remember and use in my testing. Often times it is hard to pick were to start looking for problems in your code , or how to identify those problems. This mnemonic seems like a good way to fix that.

From the blog CS@Worcester – Dhimitris CS Blog by dnatsis and used with permission of the author. All other rights reserved by the author.

In this article, James Bach talks about the ways in which conversations about testing skew away from the reality of what it means to actually do software testing, and what it means to be a skilled tester.  As is clear from the title, he divides this broad topic into six smaller pieces:

1. Size doesn’t matter.  The number of test cases that you run is not a meaningful number, just like the number of lines of code in a project is not meaningful.  What matters is what they cover and what they can teach us.
2. Tests are performances.  It’s an activity, not an object.  The person implementing test cases is more important than the cases themselves.
3. Testing strategy needs to evolve.  Testing is a process of constant interrogation (I’ve written about this before in response to other articles) of both the code and the tester.
4. Automation does not define testing.  Automation is a tool with which to run tests.  It takes human judgment and skill to design and implement quality tests.  Automation is a way to do a lot, but it takes a tester’s skills to do a lot with as little as possible.
5. There are many kinds of test coverage.  No one type of coverage is truly comprehensive, and making changes to tests to give additional coverage by one metric may change what is covered by another metric.
6. Testing is not static.  It’s an activity that’s fundamentally about learning.  Some things are predictable, but many things are not.  Testing is essetially formulating and then running experiments.  Much can be gained by deviation from established procedures.

The biggest takeaway for me from this article is the notion of testing as design and execution of experiments.  It’s not something I’d ever really thought about before, and it makes a lot of sense.  Testing is the process of formulating a hypothesis (these inputs in this context should result in this output) and then trying it out to see whether it’s right.  It even involves fairly thorough hypothesis testing, so that we can claim with confidence that a particular outcome of use is guaranteed (or close enough).

This article is also a discussion of the ways in which one can have a useful conversation about testing, and the ways in which those conversations can turn useless.  I think this is important to take away too, when I’m looking for jobs in the software development field.  I want to avoid making conversational mistakes in interviews by going down the wrong path, and I also may want to avoid working at a company where those conversational mistakes are part of the corporate culture.

article link

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

This week I read an article called “Why Testing Matters (https://blog.smartbear.com/software-testing/why-testing-matters/).  It’s easy to take testing for granted and start to think it is less important when everything is going right.  When testing is not taken seriously though serious problems can arise.  The article touches on a  few recent issues to further cement the point of the article that testing plays a critical role.  The first issue is that the iOS 11.1 update causing the letter “I” not typing and a crackling sound during calls.  This can be detrimental to a company especially one like Apple that has strong competition with Android and people are quick to switch phone types after a few issues.  Android is not without their own testing issues though.  The Android OnePlus 5 disconnected users who tried calling 911.  It’s important to remember that faults and errors are not only a slight annoyance to the end user, but can also cause dangerous situations for your users.  The one that stood out to me in the article is a software bug that revealed the names over 1,000 Facebook moderators to hate groups that were being watched for posting inappropriate content including potential terrorist organizations.  This puts Facebook’s own employees and their families at risk.  Beyond that it is also a reminder how easily our personal information can be exposed just by ignoring or overlooking a few simple tests.  A few additional hours of testing and work can save your end users many months or even years of head aches and problems dealing with identity theft.  There were also issues that were found with the global positioning system ground software.  Due to software issues there was an error of 13 microseconds.  While that doesn’t seem like a lot that averages out to be just under four kilometers off course.  This is a very serious error in positioning and navigation and can cause errors for millions of users.  Since software testing was not seen as a priority a delay in testing caused a new fleet of passenger train cars in Oakland to deal with overcrowded trains to be delayed.  While the exteriors of the cars are being built on schedule the delay in testing is bottle necking the process.  I like this blog because it shows a broad spectrum of issues and in different industries.  That’s good because it helps promote the idea that software testing is needed everywhere and it’s not just for a company that only produces commercial software.

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

This week, I thought it would be useful to look into how testing is conducted in TypeScript, to follow up to Post #8.  I found a blog post by Sudarsan Balaji, entitled “Unit testing node applications with TypeScript — using mocha and chai”, that describes the process of using the assertion library chai in conjunction with the testing framework mocha to conduct unit testing on node applications written in TypeScript.  I believe that knowing how to conduct proper unit testing in TypeScript will give me an advantage in the upcoming assignment as well as the final project of the semester.

Balaji begins the article by explaining his reason for advocating the use of mocha and chai, specifically, and also how to install them.  As I explained in the introduction to this post, mocha is a noteable JavaScript testing framework and chai is an assertion library (a collection of tools to assert that things are true/correct).  Balaji believes these these two tools work well together because they are simple yet effective enough to get the job done.  I’m not going to explain the installation, here, but once you have mocha and chai installed, you simply create a new TypeScript file and invoke some import statements.  Balaji then provides an example of a TypeScript test (I added some comments for clarity):

/** hello-world.spec.ts */
import { hello } from ‘./hello-world’;
import { expect } from ‘chai’;
import ‘mocha’;

describe(‘Hello function’, ( ) => { /** test group name */
it(‘should return hello world’, ( ) => { /** specific test */
const result = hello( ); /** run hello( ) function from hello-world program
expect(result).to.equal(‘Hello world!’); /** compare result to expectation */
});
/** to test something else we would just add more it( )statements here */
});

Sample expected output:
Hello function
√ should return hello world

1 passing (8ms)

To run this unit test, Belaji recommends creating an npm script that calls mocha and passes in the path as a parameter.  This can be done, for this example, by creating a JSON file with the following contents:

/** package.json */
{
“scripts”: {
“test”: “mocha -r ts-node/register src/**/*.spec.ts”,
},
}

(For those unaware, a JSON file is a JavaScript Object Notation file.  JSON files are written in JavaScript object notation and are used for storing in exchanging data.  In this example, we are using it to store a script that we will run from the console, using npm.  i.e. npm run test)

The remainder of Belaji’s post is a discussion of using mocha and chai to conduct unit testing on client-side applications.  The final project may require me to delve into this aspect of TypeScript testing, but because I have yet to begin work on the final project, I think I will refer back to this section of his post and summarize it later, if I feel the need to.   Given the nature of the projects we are working on, right now, I think it is sufficient to stop this post here.  I now have an introductory understanding of how to conduct unit testing in TypeScript, which I can now use to assure that I am producing quality JavaScript applications.

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

http://javarevisited.blogspot.com/2016/08/adapter-design-pattern-in-java-example.html
This week we turn to the adapter design pattern. The adapter design pattern is one of the most useful of the GOF pattern. This article is a good summation of its intent and purpose in software engineering. As stated in the blog post, the adapter design pattern, also known as the Wrapper pattern, helps to bridge a gap between two classes. Similar to the decorator design pattern, it is a structural design pattern. Its main intent is to bridge a connection between 2 classes with different interfaces. It allows the two classes to work together without having to modify the internal code on either side of the classes.
A good analogy provided in the article is that electricity adaptors from different countries. For example the US has rectangular socket while India has cylindrical ones. The main point to get at from the socket example is that the sockets of the visiting country and the plug of the laptop never changes, but that the adapter bridges a gap between them. Altogether, the adapter design pattern makes incompatible interfaces work together, without changing either of the interfaces’ properties.
An interesting aspect of the adapter design pattern is that it can be implemented in 2 different ways. The first uses inheritance and is called the Class Adapter pattern. The second is through composition, which is known as the Object Adapter pattern. Of course, as what we have learned for the strategy design pattern, composition provides for more flexibility and code reusability. Composition is favored over inheritance. So, the Object Adapter pattern is often prefered over the Class Adapter pattern.
The main use of the adaptor design pattern is to independently add responsibilities to individual objects without affecting the other objects. This means that responsibilities can be independently withdrawn just as it can be independently added. Finally, when extension by subclassing is impractical, the adapter pattern can be used.
The main reason for introducing the adaptor design pattern this week is to learn about its useful in software development to incorporate into future designs. The adapter pattern like all of the other design patterns encountered thus far in the course allows for code reusability. It acts as a wrapper to the connected interfaces. It allows what would have been incompatible interfaces to work together and provides for loose coupling between the two. It can also be used for conversion classes. A good example provided is that to do calculations in miles but the library used only expects kilometers. In this case, the adapter class can take miles from the Client and converts it to kilometers. It can then leverage external library methods for all of the calculation. Kilometers can then be converted back to miles and the results can be sent back to the Client. Finally, to close off this week’s blog post my favorite example of the adaptor design pattern is in third-party libraries. The adapter design pattern allows for code reusability and for easy addition and removal of responsibilities. This allows you the flexibility and more control to replace third-party library with better performing API. This is the reason why I chose this topic this week. To learn about the advantages of using the Adapter design pattern to incorporate in my own coding style.

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

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.