In this final week of blogging for CS-343, I wanted to look over the General Responsibility Assignment Software Principles, or GRASP.

I took to learning about GRASP from Code Specialist at https://code-specialist.com/code-principles/grasp/, which discussed all nine GRASP principles and provided diagrams and code examples.

I’ve learned that the nine principles are: controller, creator, indirection, information expert, low coupling, high cohesion, polymorphism, protected variations, and pure fabrication.

Controller: helps “control” (not implement) events indirectly related to the user interface. It acts as a mediator between signals from the user interface and the backend.

Creator: a class responsible for the creation of certain objects, such as object A. This principle has a few rules for the creator, which are: creator B aggregates instances of A, B contains A objects, B records instances of A objects, B closely uses A objects, and B has the inputs for when A is created.

Indirection: is an idea that works with other concepts, like low coupling. It serves to avoid direct coupling. For example, the controller is an indirection between the UI and backend.

Information expert: a class containing the information needed to decide where an operation should occur. The operation should occur where most of the input needed for it is stored.

Low coupling: the idea of little interdependency between modules. By having few dependencies between modules, it would be less complicated to make changes to the code.

High Cohesion: describes the flow inside modules, not between them. High cohesion mainly helps to reduce complexity. Classes should be made to only fit their purposes and not go beyond that scope. We should not have large classes that do not really relate and are hard to work with.

Polymorphism: there are many variations of the same method and they work differently in different classes.

Protected variations: wrap unstable code with a stable environment. The unstable code can be wrapped with an interface that creates multiple implementations of that code.

Pure fabrication: creating a class that does not represent a real-world problem, but serves to support low coupling and high cohesion.

I thought this was a nice source to learn from because the page has neat orientation and provides diagrams and some sample code. Many of these principles seem interconnected with other principles to help reduce the complexity of code. High cohesion reminded me of the SOLID design principle single-responsibility principle in which classes have one responsibility and should not cover more than that responsibility. It would make the classes easier to understand, and less changes would need to be made to the class if it covers less functions. All of these principles I have learned will help me write neater code in the future as I keep in mind the need to reduce interdependence and complexity.

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

I wanted to focus my last blog post on frontend development because I think I have a better understanding of the backend than the frontend, and while I think I get how the frontend works and what is going on in it, I was having trouble in the latest activity adding to the frontend that we were given and connecting it to the backend. I also had to make some edits to my assignment and could talk about what I had trouble with.

First, with the last homework assignment, I had a few issues with adding onto my frontend. When I made the new filterByName button, I did not add it to the data() section, which would cause an error. I added the button and the status I used for it to the data() section and gave them default values similar to what was already there. My other two issues had to do with my filterNames method, where I was stating the endpoint to get names incorrectly, and I had the resulting response given to the wrong variable. I was a little stuck at first changing my endpoint name because at first I changed it to just /items instead of items/{name}, which I had before and is not the correct way to get to the endpoint. I was trying to add a name variable to the get method as a way of getting the names, but after looking through the frontend example, specifically versions v2 and v3, I saw that I could just connect to the names of the items endpoint with /items + itemName. The last issue was sending the response to the wrong variable because I had it set to just a names variable, but I changed it to a filter variable to show that the result is being given to the resulting filter, not changing the actual names in the endpoint.

I also did some more into endpoints to see if there was anything I was missing when it came to understanding the frontend. I read an article called “What is Front-End Web Development?’ by Trio Developers, and most of the article was a review of what I knew from the previous article I read for the blog: The frontend makes up the interface of the program that users interact with, and the frontend uses different elements that can be interacted with to go through the site, such as drop down menus and sliders. The frontend is immersive for the user interacting with the site.

The article goes on to talk about what frontend developers do, and their jobs focus on developing interfaces for code, improve upon applications, and work on UI/UX designs and their usability/feasibility. It also goes into the differences between the frontend and backend, but I already talked about those in the previous blog post.

I think I correctly fixed my mistakes on my homework assignment, and while the information from the article was mostly review, it was still a good read and I liked how it talked more about developers and what their jobs are.

https://trio.dev/blog/front-end-web-development

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

https://www.dossier-andreas.net/software_architecture/pipe_and_filter.html

The Pipe-And-Filter architecture is conceptually very simple. It essentially consists of breaking down one operation into a sequence of smaller operations, in which the input of each is the output of the previous. These operations are called “filters” and the connectors linking them are called “pipes”. Sometimes the terms “pump” and “sink” are used to refer to the initial input and final output, respectively. I think making up those last two terms is a little excessive, but overall I like the metaphor – it makes me think of an actual physical machine, which is similar to how I prefer to think about computing in general.

The most well-known example of this pattern is seen in Unix and Unix-like operating systems, which are also the most obvious example of this pattern’s utility. There is no need for any program to have word counting functionality, because its output can be piped into wc, a program that only does that. Similar functionality for pattern matching is provided by grep. With this ecosystem of programs in place, a skilled user of a Unix shell has a great deal of functionality available to them through composing these programs in different ways, as opposed to creating new programs from scratch that do slightly different things than what the programs on their machine already do. Another common example is compilers, which also function in a similar way in order to streamline and simplify the process of translating between languages. The OpenGL rendering pipeline has similar motivations, only for processing graphics instead of programs.

One drawback of a pipe-and-filter system is that it has the potential to draw too much overhead. Being able to pipe something into wc rather than counting words yourself is a more flexible solution, but it does involve running a separate program. At small scales (i.e. most use cases) this isn’t an issue, but if your data is large enough you may need to abandon this system.

Before looking into this, I wasn’t really aware of the pipe-and-filter architecture as a distinct pattern. I was aware of how the Unix ecosystem worked, but I thought the practice of piping together small programs in sophisticated ways was just a quirk of that operating system. I didn’t connect the dots that it was also the same basic concept being used in graphics pipelines, even though I was aware of them. I also have always regarded compilers as a little magical, and seeing that their workflow can be decomposed like this makes them seem a little more approachable.

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

My experience with HTML programming outside of classwork pretty much begins and ends with making forum posts look fancy in 2012 messaging boards, and I have even less experience designing frontends with HTML. I wanted to use this blog post to learn more about how to build frontends. Matias Lorenzo’s “Frontend Architecture and Best Practices for Consuming APIs” seemed like a very good start.

Lorenzo notes that issues begin to arise when designing a frontend because that frontend is often dependent on a backend API. This means that whenever the backend or the API undergoes a change, the frontend must also be changed. Lorenzo describes some other issues one might encounter when integrating an API into their frontend. APIs may use lengthy key names that necessitate mass replacement. APIs might structure data in a way that is difficult to fully utilize, or they might include too much data.

Lorenzo proposes a frontend architecture that would further isolate the frontend from the backends it depends on so that it is more stable when the backend changes and is titled model-controller-serializer. Below is a diagram of how this architecture fetches information, in this example it is fetching products for a storefront, from an API:

Controllers in this architecture are the point of contact between the rest of the app and the API. This portion of the app should be able to create any relevant request. Information comes in through the controller, is deserialized by the serializer, then is passed to the model to create instances of that information.

Serializers in this architecture decipher information coming in from the API. If an API includes information that is not relevant to the app, the serializer can remove this information. The serializer can also change the type of a field (eg. from a string to a boolean). Similarly, if the API uses long or clunky names for fields, the serializer can alter the name of the field before passing it along.

Models in this architecture are representations of information from the API that can be read by the app. These store information as an object in Javascript (or whatever language is being used in the app) so that it is easy to access and understand.

I chose this source because I wanted a more in-depth look at frontends. I know what a frontend does, but I would be at a loss for how to design one. This frontend architecture Lorenzo describes seems really useful to help keep the frontend and backend seperate, and I will be keeping this reference in mind for future projects.

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

Christian Shadis

As I transition into the final semester of my undergraduate degree, I plan to learn Javascript. In my Software Construction, Design, and Architecture class, we briefly explored and edited some frontend code in Node.js and Vue.js. Using my prior knowledge in Java, I was able to understand how most of the code was functioning. As Javascript continues to rise in popularity, it would be a valuable language to add to my skillset. One of the fundamental aspects of learning Javascript, or so it seems, is to understand the Document Object Model (DOM). Having used his book HTML & CSS: Design and Build Web Sites to supplement my knowledge in web design, I decided to consult the fifth chapter of Jon Duckett’s Javascript and JQuery: Interactive Front-End Web Development to learn more about the DOM.

Duckett first specifies the DOM as a set of rules, separate from the HTML and CSS of the website, which “specifies how browsers should create a model of an HTML page and how JavaScript can access and update the contents of a web page while it is in the browser window” (Duckett 184). In other words, the DOM acts analogously to an API in that it facilitates or enables real-time communication between JavaScript code and the HTML page. Duckett proceeds to describe the DOM tree, the benefits of caching DOM queries, and how to traverse the DOM tree. He also described how to access, update, add, and delete HTML content from the page using the DOM. The chapter included a bit of bonus information such as cross-site scripting attack prevention and how to view the DOM in each of the major web browsers.

Reading this chapter was useful in contextualizing how the different parts of a webpage interact with each other. In addition to learning the fundamentals of the DOM, I also gained experience reading JavaScript code, which is a great way to learn how a language works. What stood out to me most about the material was the parallels between the DOM nodes and the LinkedList data structure. Having coded an implementation of the data structure in a previous course, it was intuitive to see how traversal of the DOM tree worked.

I plan to continue to learn JavaScript, and plan to read the remainder of the book. Web design is becoming more ubiquitous by the day, and thus a more valuable tool for developers to have. I would highly recommend this book and others by Jon Duckett to developers – the design is pleasing, he provides sample code, and offers excellent simplistic explanations.

Duckett, J. (2014). Document Object Model. In JavaScript & JQuery: Interactive Front-end web development (pp. 183–242). essay, John Wiley & Sons.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Resource Link: http://www.kamilgrzybek.com/design/grasp-explained/

For this blog post I wanted to explore the GRASP principles. GRASP is an acronym for 9 principles that apply to object oriented design in programming, and it stands for General Responsibility Assignment Software Patterns. The 9 principles are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Indirection, Polymorphism, Pure Fabrication, and Protected Variations.

First, the Information Expert principle states that an object should have all the functionality and logic that pertains to it. For example, if a class has a list of objects, then it should also have all the logic for functions that pertain to that list, such as adding items, removing items, etc.

 Next, the Creator principle states that an object should be created within the scope where it’s used. This means that if a certain class A relies on another class B to function, and B is unique to A, then B should be created within class A.

Next, the Controller principle states that the first object behind the front end UI layer should control the backend operations. This helps to separate the front end functionality from the backend functionality.

Next, the Low Coupling principle states that objects should be designed in such a way to where they can be isolated and reused without changing many other components. This helps to avoid rewriting code that could be useful in multiple places, instead making it generic so that it can fit into many different applications.

Next, the High Cohesion principle states that objects should only contain data and functionality that pertains to their function. This helps to avoid overloading a class with extraneous information and logic that isn’t necessary and should be abstracted or put into another class.

Next, the Indirection principle states that instead of directly coupling two objects, an intermediary object should be used between the two to handle the coupling. This helps to avoid a direct dependence relationship between two objects, instead having them both rely on an in between class that handles the relationship, so that change can be localized to that one class.

Next, the Polymorphism principle states that objects should be generalized so that they can handle support for different object types. For example, an animal class would have functions that pertain to all animals, and then subclasses could have functions that are more specific to certain kinds of animals.

Next, the Pure Fabrication principle states that shared functionality between classes should be placed within a separate class rather than in a class that it only roughly fits into. This helps to abstract functionality that could be repeated among many classes, instead putting it into a single shared class.

Finally, the Protected Variations principle states that systems that are likely to change should be protected as to not affected other systems. This helps to avoid breaking systems that other systems rely on, instead making sure that systems which other systems have a dependence on are protected and not susceptible to change.

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

For this week’s blog post, I have found an article discussing software framework. Varvana Myllarniemi, Sari Kujala, Mikko Raatikainen, and Piia Sevonn, the authors of the article, say on software framework, “Software frameworks are nowadays extensively used to develop different kinds of software applications efficiently. For example, using a framework, such as Spring, Django, Node.js or Angular.js, is the de facto standard approach for developing web software.” (Varvan Myllarniemi, et. All). When selecting a framework, you will need to keep in mind that it will be a critical design decision. This is because the framework will control the application’s architecture.

There is a drawback that does come when selecting to use a framework. Due to frameworks being very complex and involve specific designs, they are very hard to learn. The current research on frameworks focus on is technical abilities more than anything else. So, there is very little research on how frameworks are picked for use in development. However, when thinking about APIs provided by the framework, there is a plethora of research from different viewpoints. The reliability and usability of the API have been the most studied. This has been more studied to it being able to reduce programmer frustration and potential bugs.

For most companies, customer need cannot be solved by development. Hence, by opening software ecosystems they can give up part of their control for faster speed and wider coverage. A definition on software ecosystems from the article can be seen below,

A software ecosystem is defined as “a set of businesses functioning as a unit and interacting with a shared market for software and services, together with the relationships among them, where relationships are frequently underpinned by a common technological platform or market” (Jansen et al. 2009).

A software ecosystem revolves around a central technology that is often now referred to as a software platform (such as an operating system, end-user application, etc.). These kinds of platforms can be accessed by end-users but also by software developers.

A platform owner will also need to provide a platform boundary resource, so a developer can build off the software platform. The authors of the article say on platform boundary resources, “The platform boundary resources are a way for the platform owner to control and influence what happens in the software ecosystem, while benefiting from the generativity of external application development.” (Varvan Myllarniemi, et. All). This is also good from companies that are also looking for a way to collaborate on similar application builds.

https://jserd.springeropen.com/articles/10.1186/s40411-018-0050-8

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

This week I looked at the pattern “Breakable Toys”. According to this pattern you have to fail at least as much as you succeed. The problem with the workplace is that failure is not supposed to happen, so if you want to learn you have to do it on your own time. You can do this by building smaller projects that are similar to what you have to do and work on them knowing that it is okay if something goes wrong. A personal wiki is a good example of a breakable toy that can teach you a lot. Even Linux was created as a breakable toy.

I like this pattern because it reinforces the idea that failure is okay. I initially disagreed with the premise that the workplace does not allow failure. Many people will fail at work and that is okay, especially if you are new in a certain field. After thinking about it I came to agree more with the author. While failure in the workplace happens, it is tolerated not encouraged. It is okay to make mistakes but you do not want to make mistakes all the time. If you are working with a breakable toy in your own time you can have catastrophic failures with nothing on the line but your own time and sanity.

This is a pattern I should try to fit into my own life. My friend David, who is also in this course, is always making some kind of breakable toy and it is really admirable. He has been doing it for years though so I should not expect to be on his level just yet. He’s even making his own programming language right now which is something I can’t even imagine myself doing.

Making breakable toys is definitely the way forward for me to improve my programming skills. More than anything I need to write more code. I need to learn more and be forced to solve more problems. Even though I have been in the CS program for three years, I do not feel I have written very much code – especially code from scratch. Most things are 80% done by the time they are assigned to me; I just put the finishing touches.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.