OO and Agile

--Originally published at Hackerman's house

There are lot of agile methodologies, each one has its own practices and characteristics, but in general they share the same philosophy. These ideas were expressed in the Manifesto for Agile Software Development.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The origin of these methodologies arises in 1990s in a world shaped by two major influences: Object-Oriented programming replacing procedural programming as the programming paradigm favored by the industry; the other influence was the rise of the internet. This situation made that the requirements started to rapidly change and shorter product life-cycles were required; this was incompatible with the traditional methods of software development. There was a need for new methodologies that could adapt to this new world.

Extreme programming

Extreme programming is a methodology which is intended to improve software quality. It advocates frequent releases in short development cycles; it uses checkpoints at which new customer requirements may be added. Other main elements of this methodology is pair programming, extensive code review, unit testing of all the code, avoiding to develop features until they are actually needed, and one of the most important ones is constant communication between the client and the programmers to assure all the requirements are being fulfilled. The origin of the name is that traditional software engineering practices are taken to extreme levels, such as pair programming that is basically extreme code review.

Sources:

https://en.wikipedia.org/wiki/Extreme_programming

http://agilemanifesto.org/

Test Driven Development

--Originally published at Newbie Programmer

Testing in Object-Oriented

--Originally published at Newbie Programmer

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

--Originally published at Newbie Programmer

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 Continue reading "Verification and Validation" →

Code Revision

--Originally published at Newbie Programmer

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

--Originally published at Newbie Programmer

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.

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.

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

Continue reading →

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.