aramirez.es

Cuando se comienza con un proyecto nuevo hay programadores que se ponen directamente a picar código como locos. Esto es una práctica totalmente desaconsejable para crea software y más aun para crear sistemas complejos. Las razones de ello son múltiples:

• Aun no se conoce (o no de forma correcta) el dominio sobre el cual va a actuar el software.
• Tampoco se tiene de forma detallada y formal la problemática que ha de resolverse.
• No se conocen las necesidades de los usuarios finales del SW de una forma completa.
• Estos puntos llevan a crear métodos y funciones con funcionalidades repetitivas o inversas, por lo que no se hace uso de reutilización de software de manera eficiente.
• Tampoco se tiene en cuenta la refactorización.
• El software será menos escalable y tendrá problemas de mantenimiento posterior.

Se podrían seguir enumerando desventajas, pero no voy a seguir aquí eternamente. ¿Qué se debe hacer pues, antes de ponerse a programar una nueva aplicación?

Para solucionar estos problemas y crear una aplicación sólida, escalable y de fácil mantenimiento hay que empezar por unos cimientos sólidos, y para este propósito nada mejor que guiarnos por algún ciclo de vida del software conocido.

Las etapas varían dentro de cada ciclo de vida, pero yo me centraré en comentar las siguientes:

1. Documentación y recogida de requisitos.
2. Análisis.
3. Diseño.
4. Implementación.

Documentación y recogida de requisitos.

Esta etapa comprende las sucesivas entrevistas con el cliente y con los usuarios que usarán la aplicación. Ellos han de transmitir qué necesitan y qué problemática debe de solucionar el nuevo software.

En esta etapa podemos empezar a hacer uso de ciertos diagramas que permitan ponernos de acuerdo con el cliente, pero por ello mismo la notación no puede ser completamente formal ya que, de tal modo, no sería legible para el cliente.

Los diagramas que se pueden usar en esta etapa son:

• Casos de uso: este diagrama ayudará a conocer los actores que intervendrán en la aplicación. Los actores pueden ser personas (o mejor dicho, papeles que tomarán éstos) u otros sistemas de software externo que hagan uso directo de la aplicación. Cada actor tendrá asociación directa con uno o más casos de uso. Un caso de uso es una funcionalidad comprendida en el dominio del SW (crear factura, buscar factura, etc.).
• Diagrama estático de clases: se notarán las clases más importantes dentro del dominio, los atributos de cada una y las relaciones entre estas clases. Por ejemplo clase Factura, Cliente, Compra, etc.

Análisis.

Una vez redactado el informe de especificación de requisitos, documentado en el punto anterior, se pasa a la etapa de análisis, esta etapa hace de puente entre la documentación y el diseño y su cometido es el de revisar, formalizar y ver funcionalidades que no se tuvieran en cuenta en la etapa anterior. En la etapa del análisis se puede usar UML estándar ya que la documentación creada en esta etapa será visible para analistas y programadores.

Los pasos de esta etapa:

• Revisión de los casos de uso. Este es el momento de ampliar el diagrama de los casos de uso con la finalidad de documentar todos y cada uno de los casos de uso y actores del nuevo sistema.
• Revisión del diagrama de clases: para tener en cuenta casos especiales de atributos, herencias, interfaces, agregaciones, etc.

Diseño.

Es el paso previo a la escritura de código (implementación), aquí es donde se tienen en cuenta la reutilización de código (uso de librerías, frameworks, clases, patrones de diseño, componentes, etc.), la persistencia de los datos (sistema de BBDD y diseño de ésta), normalización del diagrama de clases según el lenguaje de programación elegido.

Implementación.

Una vez documentados todos los puntos anteriores y con los diagramas de casos de uso, de clases, entidad-relación de BBDD y alguno opcional como: secuencias, estados, colaboración, etc. Es la hora de empezar a escribir código. ¿Contento por ésto? bien, pues puedes estar contento por dos veces ya que además de empezar la codificación del proyecto a tu lenguaje de programación favorito (o en su defecto, el elegido), también ahorrarás una gran cantidad de tiempo gracias a que todas (o la gran mayoría) de funcionalidades están documentadas de una manera formal, se tienen en cuenta grandes masas de reutilización de código, refactorización, etc. Que te ahorrarán grandes dolores de cabeza, errores, multitud de pruebas, etc.

Para ampliar conocimientos acerca de este tema, hay multitud de libros de Ingeniería del Software, UML, patrones de diseño (design pattern) y ciclo de vida del software.

Tags: Programación | UML