UNIFIED MODELING LANGUAGE(UML)

Since we have been using and seeing a lot of UML diagrams in class and in previous assignments, I decided to look for some resources on UML diagrams to broaden my knowledge and understanding. I finally settled on this resource because it gives simplified tutorials on UML diagrams making it easy to understand especially for beginners. Each part is broken down into various topics and subtopics. Page gives useful resources on UML as well.

This resource gives a clear and simplified definition of UML diagram. It has various topics that explains the roles of UML diagrams and goals of UML in Object Oriented Design. It explains the building blocks of UML diagrams which are Things, Relationship and Diagrams. It gives detailed explanations about nine kinds of UML diagrams or format uml diagrams, the three types of UML modeling and UML notations. It also gives sample examples of UML diagrams when explaining some concepts which makes it easy to understand when reading. Page also talks about the 2 broad categories-Structured and Behavioral with each divided into subcategories

In this tutorial, I learned that UML diagram is not a programming language and relates to Object Oriented Design. Initially I thought it was only a pictorial language to build software system, but this page makes it clear that it uses non-software systems as well. UML diagrams are also made for different users, not just developers to understand a software and non-software system. I must say that through UML diagrams in class, I was able to really understand the way a program is structured as well as relationships between the classes, interfaces etc. even before looking at the codes.

In the architecture part of the tutorial, I learned about the roles that UML diagrams plays in different perspectives of a system. These are the design, implementation, process, and deployment. Looking at these perspectives, all the diagrams that I have seen support this. These diagrams make clear of classes, interfaces etc., assembled in a physical state giving an idea about the flow a system/program has. Another important thing that I learned is that UML diagrams helps support the representation of physical nodes of a system that forms the hardware.

I learned that UML notations are very important to make a model that is very meaningful and is something that should be emphasized from the beginning. Some of these notations are Class, Object, Interface, Collaborations, Actor Notations, among others. I learned that the only difference between the Class and Object notations is that name is underlined in Object notations but has same structure and components as the Class Notation. I got confused when I saw a diagram of Active Class Notation as it looked similar to Class notation but I learned that the differences is that Active Class has solid borders and are used to describe concurrent behavior of a system.

I hope others find this source useful

https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm

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

Docker

Hey guys welcome to week 4 blog. This week I am going to talk about Docker and why is Important. we learn about this in last few classes and I am writing about this platform because it help me and you getting deep understand about how to operate and use this application in seitan way. so let’s start this with what is Docker? so docker is tool that designed to make it easier to create, deploy, and run application by using Containers. It includes packages, libraries and other dependencies. You probably wondering how this Work. Well it’s work on Virtual machine. It kind a uses Linux machine. And importantly, it’s open source!!!

you wondering, who is Docker for? Docker is a tool that is designed to benefit both developers and system administrators, making it a part of many DevOps toolchains. For example developers can focused on writing code without worrying about the system that it will ultimately be running on. it also allows them to get a head start by using one of thousands of programs already designed to run in docker to run in Docker containers part of the application. I have used programing platform call QT. Qt is software development platform where you can write code and make you own application and it require a C++ language to run your software. but Docker run on command line. this make developer really easy to developer application and Quicker too.

This container can be thought of as necessitating three categories of software: Builder, Engine, and Orchestration. the main point of using this is making application build faster and docker is way to do it.

Now I will tell you why Docker is good for data Science. When I started as a Data Scientist my focus was always on finding the best algorithm by conducting experiments that would improve my model’s performance. I never really thought much about how I would share my findings and code with others, other than Most of this was the environment setup. In many cases, it would be time-consuming and I would give up and get on a call with the main Developer. when you data Scientist you deal with data a lot and also as algorithms. when you run data in Docker you build Docker Image , Run Image.

Sours: https://opensource.com/tags/docker

https://www.docker.com/blog/

From the blog CS@Worcester – </electrons> by 3electrones and used with permission of the author. All other rights reserved by the author.

Simple Factory Pattern

Last week I gave you a small introduction in design pattern and explained their benefits in codes. Today I want to talk about one of this design patterns. The Factory Pattern. The reason why I choose this pattern is because I had to use it in one of my projects in java. The Simple Factory is not actually a Design Pattern; it is more of a programming idiom. But it is commonly used, so we will give it a Headfirst Pattern Honorable Mention. Just because Simple Factory is not a REAL pattern does not mean we should not check out how it is put together.

So, what is a simple factory pattern? The Factory Method Pattern defines an interface for creating an object but let us subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. As with every factory, the Factory Method Pattern gives us a way to encapsulate the instantiations of concrete types. As in the official definition, you will often hear developers say that the Factory Method lets subclasses decide which class to instantiate. They say “decide” not because the pattern allows subclasses themselves to decide at runtime, but because the creator class is written without knowledge of the actual products that will be created, which is decided purely by the choice of the subclass that is used.

When to use the Factory Design Pattern in Java?

Static Factory methods are common in frameworks where library code needs to create objects of types which may be sub classed by applications using the framework.        

Some or all concrete products can be created in multiple ways, or we want to leave open the option that in the future there may be new ways to create the concrete product.

Factory method is used when Products do not need to know how they are created.

We can use factory pattern where we have to create an object of any one of sub-classes depending on the data provided

There are a lot of examples about the Factory Design online. A lot of website gives a good explanation. I decided to choose the Headfirst Design Patterns by Elisabeth Robson; Kathy Sierra; Bert Bates; Eric Freeman. The chapter four shows talk about this pattern and shows a very good explanation and an example also. Another website that it helped me to understand it better was javarevisited. Again, it explains it with details and examples how it works.

https://javarevisited.blogspot.com/2011/12/factory-design-pattern-java-example.html#:~:text=Factory%20design%20pattern%20is%20used,just%20change%20in%20one%20class.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

You Ain’t Gonna Need It

Hi everyone and welcome to the week 4 of the coding journey blog. For this week’s post I will be talking about a principle called YAGNI which is an abbreviation for you ain’t gonna need it. Now this may seem like a simple topic, but it is very important concept that often gets overlooked in the early stages of programming.

You ain’t gonna need it is one of the key principles to extreme programming and the XP co-founder has states that you should always implement things when you actually need them, never when you just foresee that you need them. The basic concept behind this principle is to do the simplest amount of work that would also get the program to work. The goal is to cut down drastically on unnecessary work, and as a result of this there will be higher productivity rates as well as a more simple to understand code. Efficiency is key when it comes to programming. A software can have many lines of code and functions, but this will be an issue if there are much simpler ways to implement those same functions with a lot less work. The process will take a lot longer with more features and down the line make it much more difficult to maintain.

There are a lot of problems that can occur if you try to implement a feature early when it is not necessary at the moment. There are three things that could happen which include having the wrong feature, having the right feature but it is built wrong or the most ideal option is having the right feature that is built right. Now with these results of the features there is also the outcome of costs. The different costs include cost of building, cost of delay, cost of carry and cost of repair. The cost of building is all the effort spent on analyzing, programming and testing a feature. The cost of delay is the lost opportunity to build and release another feature now. The cost of carry is the complexity added by the feature to code, which makes the software harder to modify and debug. The cost of repair is the effort spent on modifying a feature because it is not exactly what you need now. Now these concepts are the input and output as they go hand in hand. If you make the wrong feature then you have to pay the cost of building, carry and delay. If you make the right feature but it’s built wrong then you have to pay cost of repair, carry and delay. Now with the best option if you make the right feature and it is built right then you just pay cost of carry and delay.

In my personal case, I plan to follow the YAGNI principle in all my future projects because it help simplify projects and saves time. It improves my productivity and prevents unnecessary work and problems.

Check out these additional resources: https://medium.com/better-programming/yagni-you-aint-gonna-need-it-f9a178cd8e1

YAGNI

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Thoughts on YAGNI

The link at the very bottom is an article focusing on a design philosophy YAGNI which is one of the topics we’re supposed to cover in class, though we haven’t gotten to it yet as of my writing this. The name is an acronym of “You Ain’t Gonna Need It” which is basically means if the situation doesn’t immediately call for something to be done, then don’t bother with it. The acronym’s meaning is also the main reason why I chose to write about this topic; it sounded funny to me. The article goes on to describe four “costs” that YAGNI mitigates. The first is the cost of build which is the time and effort spent on analyzing, programming, and testing something. The second is cost of delay which is the cost of pushing back other priorities in order to work on what is deemed more important. The third is cost of carry, the complexity that something brings to software and how that modifying and debugging more difficult. And the last is cost of repair which is self-explanatory. By only working on what is immediately important, the chances of wasting time or changing the program are reduced significantly.

What I find interesting about YAGNI is that in a way, it’s telling people to wing it. The biggest reason for that is because in everyday life, sometimes plans change because of unforeseen circumstances. Let’s take for example someone meticulously planning out a program while taking multiple scenarios into consideration and designing different components to compensate. But it later turns out that many of these scenarios are either unlikely or are taken care of by other things outside of the program that this person didn’t even know about. That in turn causes cost of carry because of all the components complicating the core program, cost of build from the time and effort wasted on designing and implementing these components. These are a lot of headaches that are solved by just being lazy and that’s kind of funny to me.

Something else I noticed is that YAGNI is a really simple design philosophy, to the point where it isn’t strictly constrained to software design. Another example I’ll bring up is how when I was younger, I would waste time writing essays by agonizing over small minute details. And a piece of advice I would often get is to write out my first draft no matter how horrible and worry about fixing the details when the time comes. That isn’t to say that drafting out an outline isn’t important; this applies both to essay writing and software design. The truth is that there should be a balance between YAGNI and other design principles which the article does acknowledge even though it does downplay it.

Link: https://martinfowler.com/bliki/Yagni.html

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

CSS Grid: A Better Layout System

Whenever I find myself working on a website, one of the more time-consuming aspects of development is often the CSS (cascading style sheet) code which controls the layout of the site. While CSS properties often have names which are self-explanatory the various formatting tools in CSS can oftentimes be confusing to me.

In the past, using the float property and various div classes to control different sections of the website was my go-to when building webpages for practice. This has since been proceeded by a number of new layout systems now baked into CSS functionalities as more recent versions of CSS have worked to better support modern web-development concepts. As I am looking to improve and modernize my web-development skills to prepare for contract work in the future, it was important that I start looking into the newer layout systems provided by CSS.

The newest layout system introduced by CSS, CSS Grid, is a fairly recent invention. I was looking for a good reference to introduce me to the idea, and I found a great resource on the website css-tricks.com (https://css-tricks.com/snippets/css/complete-guide-grid/), which focuses on providing relevant information regarding various CSS standards and techniques. The article provides a complete introduction to the idea of Grid, starting with it’s various properties (display: grid to begin using the layout, various grid-template properties and grid-column/grid-row to control the particular layout of content) and moving further to discuss more specific techniques associated with Grid. I felt that the information about defining gutters (spaces between grid items) was extremely helpful, as gutters vs. borders in web design has been a hard topic for me to wrap my head around for a while, and this page put it into a really easily-understandable format in my opinion.

CSS grid is absolutely what I would use for a modern website design if I were making a site for someone in 2020. Although there exist frameworks such as Bootstrap and Skeleton, a lot of the inner-workings of the page and its layout can be obstructed in a way, and I feel like Grid makes it easy enough to make a great layout without relying on an external framework. Keeping things simple in web-design has always made for a more manageable website in my experience. I would certainly recommend this article to anyone looking to explore CSS Grid as a layout option for a website, the plentiful examples and images make concepts easy to visualize, and the explanations provide a good level of information without seeming overwhelming to someone unfamiliar with the topic.

With CSS grid, I think web-development (in terms of front-end) has become much more accessible, and building a functional and aesthetically pleasing website has become far easier than in the past when reliance on outdated layout formats made things a lot more difficult.

Site Referenced: CSS-Tricks.com

A Complete Guide to Grid

Great resource for learning more about CSS grid!

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

S.O.L.I.D Principles

 This week on my CS Journey, I want to talk about the SOLID design principles. I am sure that you have heard the term many times, however, let us look at the principles in detail. The reason I picked this topic is as a Computer science major student we write many programs and having a strong principle will enable us to write effective object-oriented code. 

To start of SOLID is an acronym where each letter represents a software design principle. 

S – for Single Responsibility Principle

O – for Open/Closed Principle

L – for Liskov Substitution Principle

I – for Interface Segregation Principle

D – for Dependency Inversion Principle

 

Each principle overlaps here and there. The Single Responsibility Principle states that in a well-designed application, each class should have only one single responsibility. essentially meaning a class should only have one job. I think this is a very good concept to use because when you are working with complex programs and the class has more than one responsibility it will become a nightmare. The open-closed principle states that classes should be open for extension but closed for modification. For example, I learned that if you want to add a new feature to your program you should do it by extending it rather than modifying it which minimizes the risk of failures. Next, the Liskov Substitution Principle which explains that an object of a superclass can be replaced with objects of its subclasses without causing problems to the application. This means that a child class should never change the characteristics of its parent class.

 

The  Interface Segregation Principle is the fourth SOLID design principle that states no clients should not be forced to depend on methods they don’t use.  In other words, interfaces shouldn’t include too many functionalities since the interfaces are difficult to maintain and change over time, so it is best to avoid. Lastly, the Dependency Inversion Principle states that the High-level modules or classes should not depend on low-level modules/classes and both should depend upon abstractions because a change in one class can break another class which is very risky.

 

Overall, the blog I read talked about each principle in detail using various examples such as UML diagrams, Java programs, and other diagrams that helped me to understand each concept. I learned a lot from the blog, and I think that these concepts are all key to writing a good solid code. In the future, I will be using the principles to write effective object-oriented code. 

 

 

Here is the blog I Used:

https://raygun.com/blog/solid-design-principles/

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Design Patterns

This week I would like to talk about the design patterns. I would like to give a little intro to design pattern. As you have probably experienced by now, writing correct computer programs can sometimes be quite a challenge. Design patterns are not language specific either. Good design patterns are implementable in most programming languages, depending on the capabilities of the language of course. They also speed up the development process by providing tested and proven development paradigms.

Effective software design requires considering issues that may not become visible until later in the implementation process. Reusing design patterns helps to prevent subtle issues that can cause major problems later. It also improves code readability for programmers and architects familiar with the patterns. In addition, patterns allow developers to communicate using well-known, well understood names for software interactions.

Correctly using a design pattern is very important. Implement it in the wrong way and it can create more problems than it solves.

In my CS-343 class we worked a little with design patterns and how they work. It is uncommon to introduce design patterns and not explain who the Gang of Four are. The Gang of Four are the authors of the book, “Design Patterns: Elements of Reusable Object-Oriented Software”: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The Gang of four design patterns are divided into 3 fundamental groups:

Creational Patterns provide ways to instantiate single objects or groups of related objects.

Structural Patterns provide a manner to define relationships between classes or objects.

Behavioral Patterns define manners of communication between classes and objects.

My favorite book about design principles is “Head First Design Patterns” by Kathy Sierra; Elisabeth Robson; Bert Bates; Eric Freeman. It is one the best for the introduction to this topic. I suggest the first chapter which gives you an understanding of the design patterns. In this chapter, you will learn why (and how) you can exploit the wisdom and lessons learned by other developers who have been down the same design problem road and survived the trip. Before we are done, we will look at the use and benefits of design patterns, look at some key OO design principles, and walk through an example of how one pattern works. The best way to use patterns is to load your brain with them and then recognize places in your designs and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

SOLID Design Principles

Hello everyone and welcome back.

 This week I will be exploring three of the five design principles of OOP; Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov’ Substituion Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).

My first introduction to these principles was in reading “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin. Prior to learning these concepts, my code was messy and not easily modified. I used to put way too many methods in classes, and my child classes were not fully compatible with the parent classes. I chose this topic because we all benefit when our code is adaptable, clear-cut and easy to maintain. I chose this blog because the author presents the information in a very direct format with great examples.

The purpose of these design principles is to make our code easier to maintain, change and understand. As software engineers, a lot of the code most of us will be working on will be code that others have written. There will be others who will be maintaining our code when we are no longer working on it. When we follow these design principles, not only do we improve our coding skills, but we help those who maintain the code we have written.

Single Responsibility Principle (SRP) means that a class should have only one purpose/task that it is responsible for. This makes code more maintainable by making software more comprehensible for future changes to be made. If a single class has multiple responsibilities, editing in the future will be more complicated because we will have to make additional changes to the classes that are dependent on it. You will have to update and recompile dependent classes that are not directly related to the change you needed to make.

Open-Closed Principle (OCP) means functions, classes and modules should be written such that others can add to them but not change the core elements. When we use this principle our code, our software will give less errors when requirements change. This makes our code more robust and reusable.

Liskov’s Substitution Principle states that every dependent class should be substitutable for their parent class without breaking functionality. Our validation rules on input parameters in subclasses should not be stricter than the input parameters on the parent. Using this principle increases maintainability of our software by making our class hierarchies easier to understand.

Through utilizing these design principles, I will be a better software engineer. I am more aware of ways to improve the legibility, and modifiability of my code. These design principles will help me stay away from poor coding practice.

Blog of Inspiration:

https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea#.xq7a6fvtk

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Don’t Repeat Yourself

For this week’s post in the coding journey blog, we are going to talk about a principle in software coding knows as dry. I chose this topic for this specific week because it felt relevant to the classwork we did this past week with super classes, abstract classes and interfaces.

What dry means is don’t repeat yourself and this concept is very important for developing software. The actual principle is represented as “Every piece of knowledge or logic must have a single, unambiguous representation within a system.” Now take for example the classwork we were doing, and how there was a method in the superclass that we decided all the subclasses would also include through inheritance. Now in the subclasses, if we wanted that method to do a different version of the method such as fly or quack, then we would have to alter each and every subclass. Even if a subclass does not have the fly or quack method, we would have to add the method and have the code do nothing. Just by talking about this you can see how redundant this starts to become. Now you may be able to get by with this repetition if you’re working on a small project and don’t have much to check for. However, when it comes to larger projects this will certainly turn into a never ending nightmare. Your code breaks and you have to go through all this different code which is similar and figure out what is off. This just seems like a waste of time and effort. This is why the common notion is to use the principle of don’t repeat yourself which has the goal of reducing repetition of the same software over and over again.

The big problem with repeated code over time is that it will become very hard to maintain. If over time, there comes a big change to the code and the logic changes, then it will become a headache. All the places where the previous logic was used, needs to be altered and the big thing that will be wasted is time. If you want to create quality code, then you will also have to use quality time. It is thereby better from the get go to design code to not repeat the same unnecessary methods and logic in multiple places.

To put this into perspective on a personal level, in the past I most certainly used repetitive code and wasted a lot of time. It may have seemed like the easier option sometimes, but as I dove deeper into my projects it became more difficult to figure out the solution for bugs and tracing the code for error. In the future, I know it is the best option to optimize the best way for the code to work without repetition in order to help myself and others down the line.

To read up on more sources, check out these links here: https://medium.com/code-thoughts/dont-repeat-yourself-caa413910753

https://dzone.com/articles/software-design-principles-dry-and-kiss#:~:text=DRY%20stand%20for%20%22Don’t,unambiguous%20representation%20within%20a%20system.%22

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.