Well designed software and OOP&A

Programación orientada a objetos es algo con lo que todos los ingenieros principiantes estamos familiarizados, o al menos con el termino.

La verdad es que la programación orientada a objectos es algo mas que poder usar objectos en algún lenguaje que, vaya la redundancia, sea orientados a objectos. Es un paradigma. Una forma de desarrollar software de un manera eficiente y potente. Hoy en día la POO esta por todas partes. Pero para poder entender el porque es tan importante este paradigma hoy en día, primero hay que entender de donde surgió la necesidad de crear lenguajes orientados o los tan mentados objetos.  Y es así que volteamos la mirada a los fundamentos de la programación en bloques. En la programacion moderna (independientemente del paradigma o lenguaje) hay 2 aspectos básicos. Los datos y las instrucciones. Para trabajar con datos requerimos de variables y tipos, y las instrucciones dependen de estructuras de control y subrutinas. Durante décadas las decadas de los 70 y los 80 la programación estructurada fue la reina del baile. Consiste en algo llamado programación arriba-abajo. Y la manera en que funciona (de manera muuuy resumida) es que los desarrolladores tomas todo el problema que quieren resolver y lo empiezan a partir en pedazos pequeños, lo descomponen hasta que se quedan con problemas pequeños, que pueden resolver fácilmente. No había nada especialmente malo con este enfoque. Sin embargo, los programadores se empezaron a dar cuenta que a esta formula le hacia falta algo. Tal como menciona David J. Eck en su libro Introduction to Programming Using Java 

There is nothing wrong with top-down programming. It is a valuable and often-used approach to problem-solving. However, it is incomplete. For one thing, it deals almost entirely with producing the instructions necessary to solve a problem. But as time went on, people realized that the design of the data structures for a program was at least as important as the design of subroutines and control structures. Top-down programming doesn’t give adequate consideration to the data that the program manipulates.
Another problem with strict top-down programming is that it makes it difficult to reuse work done for other projects. By starting with a particular problem and subdividing it into convenient pieces, top-down programming tends to produce a design that is unique to that problem. It is unlikely that you will be able to take a large chunk of programming from another program and fit it into your project, at least not without extensive modification. Producing high-quality programs is difficult and expensive, so programmers and the people who employ them are always eager to reuse past work.

Y fue así que la programación orientada a objetos empezó a tomar la delantera en cuanto a paradigmas de programación. Un paradigma que le da una gran importancia a la reutilizaron de código. Esto no solo nos ahorra tiempo, sino que permite a las empresas utilizar mejor sus recursos.

En la practica al día de hoy es común que se combine los diseños top-down y bottom-up. Pero todo programa bien diseñado debe sen tan modular como sea posible, esto se traduciría en un código muy flexible. Y esta flexibilidad es una de las mas importantes herramientas que nos otorgan los principios de la programación orientada a objetos.

Software Development Life Cycle and Architecture

El diseño de software es algo muy complejo. Tiene muchas variables que pueden afectar los resultados. Desde el lenguaje que se utiliza, hasta el paradigma en el que los programadores y desarrolladores se estén enfocando para poder construir su sistema. Sin embargo, hay una serie de pasos que, independientemente de lo anterior dicho, pueden resultar muy útiles a la hora de escribir las lineas de código para poder concebir un programa exitoso. Esta serie de pasos estructurados se pueden encontrar en la forma de algo llamado Software Development Life Cycle. Podemos tomar una pequeña definición de que es este proceso en la pagina tutorialspoint.

SDLC for short, is a well-defined, structured sequence of stages in software engineering to develop the intended software product.

A pesar de que parezca un sistema muy claro y definido dentro de la comunidad informática, los pasos para llevar a cabo los ciclo de vida del software parecen variar de fuente en fuente (esto al menos en las fuentes que pude consultar). Algunos se extienden mas o menos en los pasos, pero todos, de alguna manera u otra, incluyen los siguientes procesos.

Recuperados de la pagina xbsoftware.

El diseño de Software y la arquitectura del mismo es algo que va de la mano. La arquitectura del sistema es la forma que se le da, por aquellos que lo construyeron. Sin embargo, mientras que el la vida de ciclo tiene como bastión de su propósito el entregar un software funcional, la arquitectura de software tiene un enfoque un poco diferente, pero vital para la vida del mismo al largo plazo. Una vez creada la solucionó, la figura que se le haya dado (esperando que se siguieran correctamente las secuencias para el desarrollo de vida del software) facilitara su evolución, mantenimiento e implementacion. Tal como menciona Robert C. Martin en su libro Clean Architecture: A Craftsman’s Guide to Software Structure and Design 

The strategy behind that facilitation is to leave as many options open as possible, for as long as possible.

En resumen podemos decir que para llegar a tener un software funcional y eficiente, debemos empezar por seguir los pasos del ciclo de vida de desarrollo. Pero si queremos un software que tenga un ciclo de vida largo y pueda ser fácilmente extensible requerimos de una buena arquitectura digital.