If you came here with no reason, then stay this may be helpful to you someday, If you were looking for this exact topic that you are probably not in the right place, eventhough if you stay you will lear a few things and this could be kinda helpful to you so take a seat and enjoy about TDD.

For those who don’t know what TDD is, TDD stands for Test Driven Development, which is basically is a software proccess that stands on the repetition of various steps followed by a development cycle, the software is subject of very specific test cases that allows the user to have a controll over the software.

TDD follows a cycle that must fulfill the needs of a software in which stands

Add a test

Each new feature begins writing a test. The test defines a function or the improvement of an existing function. The developer must start by fully understanding the feature and its requirements. Some of the tests can be updates of an existing test. The use of tests before starting to write code lets the developer to focus on the requirements while writing code.

Run everything and see if something fails

In this step the existing code is proven to see if the new test is passed. If the existing code passes the new test it means that the test is useless or flawed. The new test should always fail because there should not be code that fulfills the requirements yet.

Code and do more code

The next step is to write the code to pass the test. It is not that important that the code is elegant or really well written. The most important thing is to pass the test. One thing you should consider is that the code must only fulfill the test and not add more functionality beyond that.

Test it out once more

If all test cases now pass, then the new code meets the test requirements and doesn’t break any existing features.

Restructure your code

The last step in the cycle is to clean up the code. Move it when it is more convenient according to the structure of your system. Eliminate duplication and in general follow the OO principles you already know. Try that your code is readable and maintainable.

and Finally…. Repeat

You finish once process and start another one with the new structure of your code, try to implement better way to compute things and to make it easier for the computer in space and time complexity, then repeat and repeat until you feel that the software is exactly what you expected from it.

My own experience

This is a topic that I have not mastered yet, you can tell, but I had the privilege to talk to Kent Beck, who is the one that rediscovered the TDD technice a.k.a. back in the day as extreme programing, because you repeated every process and a specific task over and over again, this is definetely of the lest known process in software development and one of the most effective ones, this is probably the reason you came to this post, in order to know a little bit more about this proccedure, if you ended up here by accident I recommend you to start developing your projects this way, you will see the diference once you start implementing it.

References

https://en.wikipedia.org/wiki/Test-driven_development

For some extrange reason we ended up in this entry of my blog, and for some weird reason we are going to keep reading this post, because in this post I will answer whether or not to verify and validate our software projects.

They may seem the same topic but the real truth is that there are some differences between these two, this is a topic that would probably discuss with someone else in the future, so this is why I do this post, to make sure that whoevers reads this article could win any discussion about verify or validate software.

The two terms are going to be all around your enviroment when making a software and everyone has their own definitions about the terms, eventhough I am not an expert I will try to do my best to explain you the differences and when you can apply these terms.

Verification

Verification is the process of evaluating work-products of a development phase, this doesn’t evaluate the final product. The evaluation done decides if the software satisfies the specified requirements of that phase.

Verification is done trough reviews, walkthroughs and inspections. These check if the software satisfies each of the requirements it should.

• Plans
• Requirement specs
• Design specs
• Code
• Test cases

Activities that must be done withing

• Reviews
• Walkthroughs
• Inspections

Validation

Validation is the process of evaluating software at the end of the development process to determine if it satisfies specified business requirements. It basically evaluates if the software does what the client needs, it is directly related to the specifications done at the beginning of the project, if these were wrong in the first place then the software won’t be validated.

There are two ways to perform software validation, internal and external. In the internal way it is assumed that the goals of the stakeholders were correctly understood, and if the software meets the requirement specification then it is internally validated. External validation happens when you ask the stakeholders if the software meets their needs.

Withint this term you evaluate the whole software

The only activity that you do with the software is test it out

My own experience

Verification and validation must seem the same thing at the beggining but once you see the main differences between them and the way that you aply those into your system everything becames much clearer, and is easier to decide where and how to aply these terms in our proyects, verification has to do more with how are we building the software, and validation has to do more with is the final product the one that we needed to deliver, definitely two terms that must be know by every person who tries to build up a project.

References

Verification vs Validation

This probably one of the main topic of software developing, code revision is a quality assurance method, in which the software is checked by reading the main parts of the code, how does the code implements itself, there are some restrictions that must be fulfilled when doing a code revision that are:

• The reviewers must know what the software does
• At least one of the reviewers must not be the software author, this because he will try to understand what other people did

Usually the code reviewers must try to discover some of the quality requiremets that are

• Better code quality, improve the code’s quality by checking its redability, understability and uniformility
• Finding bugs, find the main problems of the software, where the software can’t keep doing its functions
• Learning, know the capabilities of the software and try to predict the software results
• Find better solutions, this part is one of the most important because in this one reviewers can come up with better solution for certaint problems in order to help the time and space complexity of the software

There are some different types of reviewing proccess

Formal inspection

This method involves careful and detailed execution withing multiple participants and phases, this is the most rudimental way of code review because a group of people join in place to check the code line by line, the pro of this method is that bugs are always easier to find because it is read line by line.

There is a document made at the end of the review that answers; who reviewed the code, when it happened, why was the reason of the review, which method did they checked, and the results of the revision, with this revision it is almost secure that something usefull about the code will be found.

Regular change-base

This is a more lightweight type of code review. This type uses something called Version Control, it is basically a system that records changes to a file or a set of files over the time. Github is one of the most popular applications that does this; the developers are constantly checking the changes made by every member of the team. They can see who is the responsible for the code and they can check it, but they do not dedicate the time to read it line by line.

Why code reviewing?

Code reviews require a considerable investment of effort from the software developers. Especially formal inspection has been criticized for this. The needed effort has to be outweighed by an adequate number of detected defects.

My own experience

Bugs, not compiling errors, other results from the ones expected are some of the problems that we usually face when developing a software, in these cases the only way to solve it quickly is to debug the code to see where the error appears, this method is kinda confusing and a little bit slow, so this is why the code review proccess came out, to find a proccess that could find the bugs, reviewing could save your project from death, you find everything about your code.

• https://en.wikipedia.org/wiki/Code_review

In my previous blogs we have discussed about diagrams, UML, design patterns, and so far we have already seen the basis of software design and and some of the uses of UML in software representation.

Now with these representations lets learn how to convert from the class design learned in the last post and turn it into code capable of running and be implemented in the system.

The only problem in trying to turn the diagrams into code is that if the diagrams are not well design or not understandable the code may be harder to code, and because diagrams are object oriented the code must be object oriented, that a must have requirement, otherwise the system must be harder to code even with the diagrams, with this the identity and functionality of the system will remain clean and keep the escence of your system.

There are some things to know before tryng to translate from classes to code:

• Know your system, know how does your system works, its capabilities, its highs and lows, what can it do or not, this because you will have to translate your system
• Know the way to translate, if you want to turn your classes into code first you need to know how are you going to do it, how are you doing it, know the paradigm and if the language supports your system capabilities
• Take advantage of the information you have, literaly it is not hard to translate your system if you know all the comunication within, and the behaviour of your system
• Know the atributes you will have to initialize in your code
• Every methods name indicates what the class must do, as an example the buy method should let the user to buy something so a product, a client must be some of its elements
• The inheritance in the system indicates how the classes communicates, the only thing you have to do is implement the design you already have
• Enjoy your coding, don’t get frustrated if the first time you try to translate it it does’t work mistakes are made by everyone so get fun coding

My own experience

Through my experience I have faced many challenges while building a project, this because sometimes you code too much instead of analysing the system you want to build, so you have something like an spaguetti code that has no head no bot, and somethimes you analyze your system too much that when you want to build your project it actually becomes very hard to code so what you wanted your system to be seems almost imposible to code, so when you analize your code just enough and start to code just the needed you system becames wxactly what you wanted and if there still some free time you can try to add a few implementations to the system.

In the previous entries we talked about how useful can UML be, this time we are going to focus in something a little different, we are focusing on database systems and how does we can represent it using tables.

When using a database system there is a situatin that happens everytime, and that is that variables and information shared in the system are not easy to read or easy to get, the comunication between the system and what does the system storages are information needed by the users, hard to get without using an organization system.

In order to map the objects in the system first you must start with the data atribute of the class, it is important to define how manny attributes of the system will be mapped, it can be from zero to any number.

Some of these elements in the system are used just for temporal calculations and are actually not necesarry to have on the database, this allows the user to decide wheter or not to include those elements in the tables.

The simples way to map elements of the sistem is to assign each attribute with a single column, in this way the data model and the physical model are very similar, the only diference is the key dependendiec between the two models.

Inheritance

Inheritance works as a tool when you are trying to organize a table into different inherited atributes of the system, basically the system must share a single aspect between the objects.

In order to implement inheritance in the system there are three diferent ways in which a diagram can be represented by using inheritance division whose are:

Using one data entity for an entire class hierarchy

In this way you describe a single class into one diagram that contains all the atributes of the element, with the respective primary key, this because with this diagram all the information must be revealed in one table.

Using one data entity per concrete class

With this way you can describe the data entity with the inherited atributed needed for the entity in order to get completely functional, the good part about this method is that all the infor is storaged in a single table, the problem is that if the data is modified all the children must be modified as well.

Using one data entity per class

In this way you create a table per class, every table includes a foreign key that is related to the superclass, this is a good option because it describes object oriented systems very well, and when you modify a class you don’t have to modify any other class, the only problem is that there are way too many tables.

My experience

As you see when talking about a big project it is almost 100% of probability you should shot how does the data of the system comunicates, and how are the classes stuctured, it has happened to me in previous projects and with this type of diagrams the system becames easier to understand not only to the developerts but to every reader of the system, a must try way to describe how is the structure of the system.

References

• https://www.ibm.com/developerworks/library/ws-mapping-to-rdb/

As we saw in the previous post, UML is the most common model used nowadays, because how easy to read and write the model is. The purpose of this post is not only to get you in contact with UML model but to let you know why should you start using UML as your default modeling languaje.

This time we are going to discuss about state diagrams, package diagrams and componen diagrams, whose are basicaaly UML diagrams that describes the project’s components in a more detailed way.

State Diagrams

State Diagrams AKA Statechart diagrams, are mainly used to describe the different states that of a componen in the systtem, it is called state machine diagram because it works like a machine, that describes the component’s state and does it change based on the events.

One easy way to understand how does state diagrams works is with this example of how does chess pieces move.

State diagrams are mainly used in back and forth projects like turn based games, and priority procedures.

Package Diagrams

A package diagram is a diagram that shows the organization of the elements in the system, within this diagram the information shown can be both structural or dependencial, with this model users are allowed.

This diagrams are mainly used to organize large systems, which contains diagrams and documents, basically a collection of logical elements UML related.

Component Diagrams

When dealing with a big project usually we usually face the problem that componets are way to big and hard to describe them, component diagrams are usually used to break down the system into smaller pieces, this to make it easier to understand it.

Lambda architecture is one of the best examples of how does component diagrams can be used, Lambda architecture is a complex architecture that be presented using components diagrams, easy to read and easy to understand, this system is commonly used by companies for storing and and processing data in the system, that is divided by three layers, speed, bathc and serving

My experience

Uml is definetely my favorite modeling language to use, not because it is easy but because literally UML has ways to express any single detail of any project, this make it easier for the users to understand the functionality of the project, the components and their behaviour.

Probably this post is a little more explanatory about the components of UML, but this is because I want you to have a little more experience with the topic, and I am trying to invite you to use UML, I assure that you will see how easily and practical UML can be in every of your projects.

References

• https://tallyfy.com/uml-diagram/#component-diagram
• https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-package-diagram/

As you can see in my previous posts, I have already wrote about UML, which is a Modeling Language, for those who don’t know what UML means, it means Unified Modeling Language, as its definition says UML is a Languaje, that allow you to model the characteristics of a software, this is one of the most used models nowadays because this language describes the comuniation of the elements of any software in a way that everyone who sees a model in UML format can understand how does the software comunicates, It is easy to implement and easy to read.

During this post I am going to explain to you the basics of UML, and in the next post I am going to give you a more in-depth of UML, for now lets learn about: sequence diagrams, class diagrams and object diagrams.

Sequence Diagrams

These diagrams could be the most important diagrams in UML, because it is not only used in computer science but in many business application software, this because it can be readed by everyone.

As its name says a sequence diagram describes the sequence of events or interactions that the software follows, this happens between actors and objects, this is describes as a cronological manner that suggesta that every interactions must be completed before or after another interaction, it can be described as a must do before do something else method, which makes it easy to read and understand.

This is an example of a sequence diagram:

Class diagram

Class diagrams are the most common UML diagrams for software documentation, this because it described object oriented programing software, and this methodology of programing is the most common nowadays this makes the class diagrams the most common diagrams in documentation.

Basically class diagrams contains classes, along with their atributes, and their behaviour, each class in the diagrams consists in three parts, the first one at the top being the name of the class, the second one in the middle being the atributes of the class, and in the bottom part the functions of the class, with this classes a line it is a attached to every class to inform the user what information does the class receives and sends to other classes, these to inform the comunication between classes in the software.

This is an example of class diagrams

Object Diagrams

This a little diferent from class diagrams, as we already saw, class diagrams are usefull because they describe object oriented softwares, but what exactly are objects, well objects are everything that the developer wants, a ball is an object, a bed is an object, everithing is an object and every objects has caracteristics and is made out of other things, can this other this be objects?, can a object be made out other objects? Well the answer is yes, anithing can be an object and and object can be made out of other objetcs, so in these diagrams every object is descibred by its functionality in the software.

In a real life example humans are objects with diferent characteristics and atributes, in order to get a job you must first give some information about yourself, just some of them because not all your information is required, to get a job you are asked to bring documents with your name, age, gender, birth date, hobbies, social status, health status, work experience, likes and things related to your capabilities at work, information like which is your favorite food is not required to get a job so eventhough your favorite food is something about you it is not needed, so the same as objects, in data science objects are made out of characteristics needed for the software, and not by every aspect of the object, these models describes the characteristics needed of an objects and how it is related to other objects.

This is an example of object diagram

My personal opinion

In this part we saw about the basics of UML, I can easily tell that this information is really helpful because it allows you to explain your software in a very detailed way, class and objects diagrams are like brothers that goes together everytime, in all of my projects I have made a class diagram and an object diagram in ordert to understand how exactly do I want my project to comunicate, because in these diagrams every single detail is shown, and that saves you a lot of time in trying to explain your software, these are the most common diagrams nowadays for a reason and that is because are easy to make, easy to read and understand and very helpful. I do advice you to try these diagrams once, you will notice a diference if you do so.

References

Ceta,N. (2019). All You Need to Know About UML Diagrams: Types and 5+ Examples. Tallyfy. Retrieved from: https://tallyfy.com/uml-diagram/#object-diagram