Object Oriented and Agile

The Agile software development it’s a set of methods and practices expressed in the Agile Manifesto, this solutions evolve through the collaboration of teams in their context, the manifesto is based in twelve principles, customer satisfaction, welcome changing requirements, software delivery frequently, daily cooperation between people and developers, face to face communication, working software is a measure of progress, sustainable development, attention to technical excellence and good design, simplicity, best architecture, requirements, and design for emerging teams and the teams reflects how to be more effective. One of this type of methods are the Extreme Programming.

The extreme programming it’s an intense methodology that is focused on improving the quality of the code and to adapt to a rapidly change of the customer requirements, as a part of agile software development it has frequent releases and short development cycles to adjust to the new requirements more quickly, in this methodology we can found things like code revision, this is done for avoid programming features that are not needed, this gives the code simplicity and clarity that is moldable for changes, for doing this is a must a frequent communication with the customer and developers, the name was taken from the software practices that are taken at extreme levels.


Agile 101

Extreme Programming: A gentle introduction


Test Driven Development

Test Driven Development (TDD) is a software development approach that relies in the repetition of steps where we use test cases before the code, if the code passes the test its accepted, this approach is different from other software developments where the software is added before it proves that meet requirements. TDD make sure that the code is entirely tested and leads to be modularized, flexible and extensible. TDD follows a development cycle where each step needs to be repeated if the test is not passed.

Test Driven Development Cycle

Add a test

The new features begin with writing a test, for writing a test the developer must have clear the future requirements of the feature this can be done by using use cases and user stories to cover the requirements, this help the developer to focus on the requirements before writing the code.

Run all tests and check if the new code fails

This step is to validate the test harness (this are the software and data configured to test a program) that is working correctly, this checks that the new test does not pass without the new code, if it passes the code already exists, this step helps to make sure that the new tests always passes.}

Write code

The next step is to write code that passes the test, the code made in this step maybe don’t be perfect and just passes the test, but the code written here is designed for testing and not for functionalities.

Run automated tests

Here if the test cases pass easily so the new code supplies the required specifications and don’t break the existing features, and if this does not happen the code must be adjusted until they do.

Refactor code

This can be compared to avoid duplication of code, this step does not break any of the other functionalities only helps to remove duplication, this helps to improve the readability and maintainability that plus value to the software lifecycle. The inheritance hierarchies are changed to be more logical with the use of design patterns, that describes specific guidelines for refactoring code.


The cycle is repeated starting a new test, the requirement for doing this is that the size of steps should be around one to ten edits between every test run, if the code don’t satisfy a new test, the programmer should do debugging. In this case the developer can use extreme programming to improve the code.


Photo by Jason Taellious
Test Driven Development (TDD)





Testing in Object-Oriented

Testing is one of the most important parts in development, because we need to make sure we are doing right and to find errors we may have and how to solve them, and this gives to the code more stability, scalability, etc.

Testing Object-Oriented Systems

Unit Testing

In this part the classes are tested individually, this test that the attributes, methods, and interfaces have no errors and are implemented as designed.

Subsystem Testing

This is testing parts of the system, it involves testing the interaction with other subsystems and outside ones, this are used when a new version is released.

System testing

This is for testing the system entirely to know if every aspect is doing well, and its used when new features are released.

Object-Oriented Testing Techniques

Grey Box Testing

There are different test cases designed for texting object oriented that are called grey box, and some of this are: state model-based testing, use case-based testing, class diagram-based testing and sequence diagram-based testing, this test cases are based in the tools of object oriented discussed in UML.

Techniques for Subsystem Testing

Thread based testing: test each class that need a single use case.

Use based testing: Each level of hierarchy its tested, the test begins with the individual classes to small modules and finally the major subsystems.

Categories of System Testing

Alpha testing: It’s the product that is testing in the organization that develop the application.

Beta testing: A select group of operated customers.

Acceptance testing: This is by the customer before accepting the product.

SpaceX Dragon Propulsive Descent Landing Test

OOAD – Testing & Quality Assurance




Verification and Validation

This are two different concepts that can be similar, but they are different, this are used in the testing part of the development. Verification: is when you evaluate the products where it stills in development and it’s not a final product, this help to know if the product its built according to the requirements and Validation: this is done when the development is finished and it’s to make sure that the product is doing what is supposed to do and supply the customers’ requirements.


Each product that we use needs to pass an international standard, this international standards are the result of different organization to suit for conditions of quality, materials, testing, that are labels that show us that the product that we are using its proved by a series of tests and to give to the customer  trust , for example in software we have the ISO/IEC/IEEE 29119 that is a series of five international standards for software testing or parts of testing, this defines the concepts and definitions, test processes, test documentation, test techniques and keyboard driven testing.

Concepts and definitions

This part one defines the definitions, concepts of the testing, and how to apply this to the other parts of the standard, this part has everything you need to know about the testing process.

Test Processes

The part two defines the test processes that can be used by the organizations that approve this standard, and this is based in a three-layer process that covers: organizational test specifications, test management and dynamic testing.

In this the risk-based approach is used, because this practice allows to focus in the most important features and quality attributes of the system that is testing.

Test Documentation

The part three as the name says its documentation. This is the documentation of the test that are going to do, this includes templates during the test process, these templates support the three test process layers explained in the part two, the templates contain the needs of each organization implementing the standard.

Test Techniques

This part four provides the definition of software test design techniques, this are the creation and writing of test cases, that can be used and implemented in the testing, this test techniques are categorized into three main categories: specification, structure and experience.

The specification test techniques are the functional specification of the system under test without observing the internal structure, the structure tech techniques are based on the internal structure of the system and here we apply the test cases, and the experience techniques are human testers that provide their experience in bugs that they expect, or they saw before in other products.

Keyboard Driven Testing

This part five uses the description of test cases using set of keywords, these keywords are associated with sets of action that are required to perform a specific step in a test case, this are easier to understand for building a test automation.

ISO/IEC/IEEE 29119 Software Testing

Code Revision

Code revision as the name says it’s when something, someone or you check the code if its correct or can have a better implementation or to make it expandable. These practices can have a lot of advantages or disadvantages depending of the people that are going to help us for this revision, this theme is part of the agile development that is based in iterative models when the requirements are changing during the development of an application, one of the most common code revision practices are pair programming.

Pair programming it’s a practice where two software developers combine effort in a workplace, one person works in the code and the other think how to improve or the next things that are need to be coded, the advantages of this is that the developers maintain focus of the things that they need to do, the code quality is better, if one developer is stuck the other can solve that more quickly, it’s helpful for beginners to learn the knowledge of another person and they improve their social abilities, but the disadvantages are that the developer with more experience can find this practice tedious and they prefer to work alone, or if they don’t have the same schedules in the day and they can’t be in the same place to work.

In conclusion code revision is very helpful for those persons who don’t have a lot of experience coding, but it’s important to choose the right person to do this.


Photo by Breyten Ernsting

Classes to Code

To convert the design of a diagram class to code in the object oriented paradigm its easy because UML in this case is made in an object oriented design so the design it’s the visual view of the code, and depending of the quality of the diagram, because if we see the structure of a class diagram is similar of how a class in object oriented is done, in the design we can see the name of the class, the attributes and type of variables, the methods and the inheritance between classes.

I wrote before the benefits of the class diagrams, but we have to consider that in this case UML is object oriented for instance only the object oriented languages can be easily to understand in UML, we need to avoid to make a mix of design and programming languages, for example to design code for COBOL we don’t use UML, we can use the UML for another languages but is not recommended for doing code but it is for only design, because UML is useful for having a big picture of the instances, relationships and how the system works.

To conclude, class to code are easy if we use the same paradigm, the trick is to choose the programming language that is our favorite and make a design is always a good idea but in preference for the same paradigm.

class diagram template for atm system


Classes to Tables

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 a primary key named orderID, and in the Products table the primary key is productID, in the other hand the table OrderDetails have two keys that are foreign keys because this are stored in another tables, and in the multiplicity we can see that Orders can have one to many items in OrderDetails, and OrderDetails belong to one Order, in the other case Products can appear many times in an OrderDetails, but OrderDetails its specified for one Products.