Classes to Tables

--Originally published at Newbie Programmer

To convert classes diagrams to database tables it’s a process that the modeling language used for doing the class diagram help us to make this transition because we know how to do class diagrams in UML, and if you compare a database table to a class diagram they are quite similar because you have the name of the class or the table, the attributes and type of variable they use, and the relationship between tables or classes, but you need to add some concepts for converting the class diagram design to a table.

First the attributes are stored in columns in the database tables, and you need to have keys, the keys are attributes that are unique in that table and you must have that key to have the attributes stored in a table, for example if we have a table with name of customers we can’t have a customer without their name so the primary key is name of the person, also we have foreign keys, this attributes are primary keys of other tables, for example we have our list of workers that they have an id from the government, this id can be extracted from another table that help us to no have the same data in two different tables to avoid ambiguity.

To show the relationship between tables is quite similar to the class diagram because we have the concept of multiplicity that show us if we need another class or table created to another table to exist, for example we can’t have a school without teachers and students, and this are represented in lines in which we have verbs, for example works for, have, controls, etc.


Resultado de imagen para database table

This image is a database of an order, we can see that the table Orders we have Continue reading "Classes to Tables"

Test Driven Development

--Originally published at Hackerman's house

Test Driven Development is a software development process that repeats very short development cycles, the requirements are turned into specific test cases, and the software is improved in order to pass these new tests. This way all the software is proven to meet the requirements set. One of the main responsibles for this methodology is Kent Beck who rediscovered the technique.

A Test Driven Development cycle consists of a series of steps. According to the book Test-Driven Development by Example these are the steps.

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 all tests and see if the new test 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.

Resultado de imagen para tests

Write the 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.

Run tests

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

Refactor code

The last step in the cycle is to

Resultado de imagen para code
Continue reading "Test Driven Development"

Unified Modeling Language Part Two

--Originally published at Newbie Programmer

This is the part two of the UML, in this case I am explaining more tools used in this modeling language, things like state diagrams, package diagrams and component diagrams.

State Diagrams (State Machines)

These diagrams describe the different states or conditions of the entire or part of the system in a finite instance of time, these diagrams are used for showing the dynamic behavior of the class and how it changes in response of the internal and external events.

Package Diagrams

It’s like a container in UML for the diagrams, these packages are sorted in groups. The packages are useful for the construction of more complex systems and behaviors, and the purpose of the package diagrams are to show a big picture of the system in complex systems because we can’t leave details in this picture.

Component Diagrams

These diagrams help to divide the system in small components that help us to know better the parts of a complex system, and this can be used to check every aspect of the system and to know if the part is doing in a good way, this is helpful when we find to see a simple top-level view of the system.

Unified Modeling Language Part One

--Originally published at Newbie Programmer

We talked about this modeling language before when we defined some examples of the modeling in computer science, UML can be used for stablishing a standard way to visualize the design of a system. UML was created by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in 1994, at 1997 UML was adopted as a standard of Object Management Group (OMG) and in 2005 published by International Organization for Standardization (ISO). We use UML because it’s a standard and it’s easy to use, because have a lot of useful tools for modeling that can be applied to code implementation. To explain a little the tools of UML I choose in this part one sequence diagrams, class diagrams and object diagrams.

Sequence Diagrams (event diagrams)

As the name says this type of diagrams describe the sequence of messages and interaction between the actors and objects, this can be active when they are needed for the communication, these diagrams are used in software development to represent the architecture of the system.

Class Diagrams

This is a diagram that is based in the object-oriented programming paradigm because this shows the common-sense relationship between the classes, the methods and attributes. This diagram consists in three parts, where the first one is the name of the class, second the attributes of the class and third the methods of the class, to represent the relationship between classes we use arrows with direction that represents the way of the association, and in each part of the arrows we have numbers that show cardinality.

Object Diagrams

Object diagrams are quite like class diagrams, this can be considered as a screenshot of the instances in the program and the relationships between the classes in a certain moment simulating a real-world scenario.



Testing in OO

--Originally published at Hackerman's house

Testing takes a big part in software development. It is important to know how to do the testing so that you can solve the problems presented and spend less time in this stage.  Object-Oriented testing is different from traditional testing. The root of this differences is that traditional programming consists of procedures operating on data, while OO testing treats with objects that are instances of classes.

Resultado de imagen para object oriented

Testing levels

There are several testing levels when you are doing OO testing.

Algorithmic level

Each module or method of every class should be tested in isolation.

Class level

Every class should be tested as an individual entity.

Cluster level

As classes are collaborated or integrated to form a small subsystem or cluster. Testing each cluster individually becomes a necessity.

System level

At this level, interaction among the clusters is tested.

Test Cases

Methods to design OO test cases are based on the conventional methods, but the should encompass some special features to that they can be used in the object-oriented environment.

  1. It should be explicitly specified with each test case which class it should test.
  2. Purpose of each test case should be mentioned.
  3. External conditions that should exist while conducting a test should be clearly stated with each test case.
  4. All the states of object that is to be tested should be specified.
  5. Instructions to understand and conduct the test cases should be provided with each test case.

Resultado de imagen para testing

Testing Methods

State based testing is used to verify if the methods of a class are interacting properly with each other. The basic idea of this method is that an object is created, and several methods are invoked to see if the object is changing states the way it should.

Scenario-based testing is used to detect errors that are caused due to incorrect specifications Continue reading "Testing in OO"

Verification and validation

--Originally published at Hackerman's house

These are two different processes utilized to test if the software we are producing satisfies certain characteristics. Both are directly related with what the client wants to build. Let’s see the differences between them and why both or them are important in the process of building great software.


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.

Are we building the product right?

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

Resultado de imagen para verify


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.

Are we building the right product?

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.

Resultado de imagen para validation


Design Patterns

--Originally published at Newbie Programmer

As the name say Patterns, this are used in the software engineering as a solution in a common problem in the software design, these patterns are not a finished solution to the problem they are a template or an instruction of how to deal with the problem. These patterns can be helpful for solving problems more quickly, to apply some software techniques to our projects and to improve the scalability and robust between the parts of the design. This patterns are divided in three categories Creational, Structural and Behavioral, and this division was made in the book Design Patters written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in 1994.


This patterns are about the instantiation of a class, the patterns can be used for creating classes using inheritance and for object creation they use delegation, and the patters that we can find here are : abstract factory, builder, factory method, prototype, singleton, and my favorite for this type is the object pool, because we can recycle objects with no use, and make it useful instead of creating another object with the same functionality.


These patterns are used for the classes and objects composition, for the structure of the classes we use inheritance to compose interfaces and for objects how to define the objects to obtain new functionality. In this classification we have these patterns: adapter, bridge, composite, decorator, facade, flyweight, private class data and proxy, proxy it’s my favorite because it’s used in representation of another object, and its useful for security of the original object.


These patterns oversee the class communication, the communication between objects like passing requests, adding elements to a class, default values, encapsulation etc. We can found this patterns : chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state,

Continue reading "Design Patterns"

Modeling Languages and Tools

--Originally published at Newbie Programmer

A modeling language it’s any language that we can use for making a model, this model can be an image, text, table, diagram, etc., this kind of languages are mainly used in the software engineering and computer science for designing software, patterns, equipment, implementations, relationships, code and its based in the requirements of the domain used for example object oriented, and there are a lot of types of modeling languages but the most typical ones are the graphical and textual ones.


In this type we found one of the most used languages UML (Unified Model Language), that is used in the object-oriented design, and the main characteristic is the use of blueprint diagrams, and we have more languages like behavior trees and flowcharts to mention some examples.


This are represented in natural languages, that is a language that we typically use that’s why is called natural we learned through the history, this type of modeling languages can be used to express knowledge like dictionaries, taxonomies, geographic, etc. This can be used to write code (pseudocode) and to make it understandable to implement in many programming languages.

There is more classification of the modeling languages like algebraic, behavioral, object oriented, for information and knowledge, but the mentioned before are the most used type and classification of modeling languages.


Photo by William Warby


Unified Software Process

--Originally published at Newbie Programmer

The Unified Software Process is an iterative process framework that can be suitable for many types of projects , this have some characteristics that defines this framework for example is an Iterative and incremental development framework that allow us to test, design and implement the product before its finished not like the waterfall model that you only can do one thing at time, second, is architecture centric that supports multiple architectural models and views and its risk focused, this means that we need to solve first the critical or greatest risks in the elaboration phase. To do the Unified Software Process we need to do four phases: Inception, Elaboration, Construction and Transitive.


In this phase it’s like understanding the project, because we need to establish what are supposed to do and the goals for the project, for this we can use a list of requirements and use cases, it’s important to have a schedule of time and the cost estimation for achieving the goals.


In this phase is where we do the risk focused part, where we need to know the critical problems and solve them first based in the requirements that we have, and it’s important to choose the architecture we are going to use considering that is useful for the project, that is good in terms of value, functionality and scalability, and to do an schedule for the Construction Phase.


This phase is where we begin with doing code and building the use cases diagram or class diagram and the implementation of each of the parts together to make sure the program its working well with making tests or changing aspects of the elaboration phase, because it’s an iterative process we can go back and solve the problem or to add things to make the

Continue reading "Unified Software Process"

CHAPTER 10 – The OOA&D Lifecycle

--Originally published at Newbie Programmer

The last chapter is important, because is about putting all the things together, all the things that we learned through the chapters are revisited and make sense when they are together, and this makes the Object-Oriented Analysis & Design Project Lifecycle that is an Iterative Development that is applied to each small problem and is iterating with every problem. And this chapter explains the seven phases and a final one of this development.

Feature List: This is necessary to do write the things that the applications need to do, when this is finished we can move to the use of case diagrams.

Use Case Diagrams: This phase helps us to thing about how the application will be used without unnecessary details. In the diagrams we are dealing with interactions between actors and the system, the features reflect functionality and use cases the usage.

Break Up the Problem: With the use case diagrams we can break this problem in smaller pieces, then we can start iterating with these pieces until the application is complete with every use case, int this phase is an extra step that is Understand the Problem before we begin with the Requirements phase because we need to understand well the problem.

Requirements: Are the specific things that the system must do to work correctly, and this help to see if the use case works.

Domain Analysis: In this phase we need to do a textual analysis on the use case and figure out the nouns (candidate classes) and verbs (candidate operations).

Preliminary Design: This phase is about making design decisions, that should be based on how the application will be used and to apply object-oriented principles.

Implementation: Here we begin with the creation and testing of the code, with doing this based in the analysis, and we

Continue reading "CHAPTER 10 – The OOA&D Lifecycle"