La Catedral y el Bazar

La historia es un tema que siempre me han llamado mucho la atención. Al igual que la programación y la computación. Por lo tanto no me parece extraño que también me guste leer sobre la historia de la computación y los hombres e ingenieros que nos llevaron desde las computadoras a base de tubos de vacío hasta donde nos encontramos el día de hoy, con computadores portátiles en casi cada hogar del mundo. Y esto es exactamente de lo que habla el texto La Catedral y el Bazar.

Cuando uno piensa en el ya conocido kernel de Linux las primeras palabras que se te vengan a la mente probablemente sean Open Source Community. Eso sin dudas es algo que ya conocía. Lo que me resultaba extraño era como algo tan grande y complejo como el kernel de linux (15 millones de lineas de código según estimaciones recientes) puede mantenerse funcional si prácticamente toda la comunidad de linux esta metiendo manos en el código en todo memento. Siempre me había quedado interrogante, y aunque había buscado varios videos y documentos del tema nunca me tope con una respuesta que me complaciera al cien por ciento. Hasta que me tope con este documento. Y resulta que la respuesta que habia esta buscando se encuentra en algo llamado desarrollo estilo bazar (termino que nuca habia escuchado en mi vida).

El autor continua contando su historia (y la de su proyecto de correo open source) y como el también se topo con la misma interrogante que yo. Todas esas dudas lo llevaron a desarrollar un proyecto a base de una comunidad entusiasta que fungían como sus asistentes no pagados, muy al contrario de un desarrollo estilo catedral.

Es un texto muy enganchante y hasta divertido. Ademas de explicar a detalle las fortalezas de un proyecto desarrollado de manera abierta. Si tuviera que decir cual fue la parte del texto que mas me marco o la que mas me llamo la atención, me quedo con la segunda regla que nos muestra el autor:

2. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).

 

Modeling Languages and Tools

Los lenguajes de modelado no son nada nuevo dentro del mundo del desarrollo de software. Son una herramienta que nos ayuda a describir como es que nuestro sistema esta conformado, como interactuan entre si y cuales son los atributos y entidades que lo conformar. Los lenguajes de modelado muchas veces se apoyan de entidades gráficas para dar un entendimiento mas sencillo y eficaz de código que compone el sistema.

Existen muchos lenguajes de modelado, entre ellos están el OBM (Object-Role Modeling), SOMF (Unified Modeling Language) y UML (Unified Modeling Language) siendo este ultimo el mas conocido y utilizado en la industria (ademas de ser el único con el que yo he trabajado).

1280px-UML_logo.svg

De UML se desprenden algunas variantes muy útiles y conocidas, entre ellas encontramos sin dudas la variante mas conocida de todas UML 2.0 y SysML.

UML es una herramienta con la que he trabajado desde que entre a la carrera de ISC. La he utilizado mayormente para trabajar con Java y SQL. Una definición muy concisa de que es exactamente UML la podemos encontrar en el libro UML for Java Programmers de Robert Cecil Martin (libro que empece a consultar desde que lleve la clase de Software con el profesor Palomino) donde nos resume que el Unified Modeling Language:

is a graphical notation for drawing diagrams of software concepts. One can use it for drawing diagrams of a problem domain, a proposed software design, or an already completed software implementation. Fowler describes these three different levels as Conceptual, Specification, and Implementation. This deals with the last two.

En cuanto a las herramientas software que he utilizado para desarrollar mis diagramas UML he trabajado principalmente con dos. La primera es una herramienta gratuita y en linea llamada UMLetino.umletino screen

La segunda es de paga, pertenece a Windows Office, lleva el nombre de Visio 2016 y requiere instalación. Pero ofrece muchas mas opciones en la parte gráfica ademas de una GUI mas compleja. En lo personal me ha resultado la herramienta mas útil para aplicar lenguajes de modelado.microsoft-visio

Use Cases

Los Use Cases o casos de uso se pueden resumir como los pasos que un sistema debe tomar para hacer que algo suceda. De principio parece una definición muy vaga, pero si la tomamos aparte y analizamos detenidamente veremos que de hecho es una definición muy precisa y fácil de entender.

Los pasos que el sistema debe tomar son representados por lo que llamamos caminos. Un caso de uso puede tener varios caminos, siempre uno principal y los demás serán caminos alternos, pero independientemente de que camino tomemos todos deben llegar al mismo lugar. Y ahí es donde entra la segunda parte de la definición “hacer que algo suceda”. Ese algo es nuestra meta especifica. La meta es lo que queremos que nuestro sistema (software o código) lleve a cabo. Y es vital tener en cuenta que cada caso de so debe tener una y solo una meta especifica. Si queremos que nuestro sistema lleve a cabo varias tareas, lo suficientemente independientes una de la otra entonces necesitaremos varios casos de uso.

Los casos de uso deben usar un lenguaje que tanto los ingenieros como los licenciados puedan entender 🙂 No un lenguaje técnico.

Hay 3 partes básicas que componen un buen caso de uso

  • Un objetivo claro
  • Un inicio y un final
  • Un indicador externo (ya que TODO caso de uso se inicia por un indicador externo al sistema)

A a hora de desarrollar los casos de uso es muy importante desarrollar de manera especifica todos los casos de uso, escuchar a los clientes y así poder encontrar todos los caminos posibles que se requieran para poder llegar de principio a fin sin importar que factores externos del mundo real puedan presentarse. también mencionar que los casos de uso nos ayudan a escribir buenos requerimientos, y esto es vital si se quiere tener un software optimo y funcional. En el siguiente diagrama que creer se muestra de manera breve pero concisa como interactuan los casos de uso, los requerimientos y nuestro código.

casos de uso diagrama

Y aunque parezcan cosas separadas la arquitectura y los casos de uso son algo que va de la mano a lo largo de todo el proceso de desarrollo del software. Tal como menciona Robert C. Martin en su libro Clean Architecture 

the architecture of the system must support the intent of the system…….Indeed, this is the first concern of the architect, and the first priority of the architecture. The architecture must support the use cases.

Y no olvidar que los casos de uso deben ser fáciles de comprender. Si nosotros o alguien del equipo (eso incluye a los licenciados) no los entiende debemos volver a escribirlos.

Unified Software Process

También conocido como Unified Software Developtment Process (USDP) es lo que muchos consideran como un proceso de desarrollo software industrial “estándar”.

Para entender bien como funciona y se implementa este modelo debemos mencionar algo, y es que apesar de que su nombre lo describa como un “proceso unificado” en realidad no es un modelo tan bien definido. Tal como menciona el profesor Praveen Mitran

el USDP es un Framework e incorpora otros métodos/modelos 

por lo tanto, al usarse con otros modelos, la implementacion cambia segundo quien o quienes lo estén implementando. Sin embargo mantiene dentro de sus margenes los mismos objetivos. El USP nos ayuda a distribuir nuestro tiempo y esfuerzo a lo largo del ciclo de vida del software. Algunos de los distintivos de este Framework es que se enfoca mucho en la arquitectura de software y en los casos de uso. Una de sus mayores ventajas (en especial la que mas me llamo la atención) es que toma mucho énfasis en mitigar y reducir riesgos. Ademas es una herramienta que es fácil de adaptar y flexible. Pero todo esto también cuenta con alguno cons. Por ejemplo, en una herramienta un tanto complicada de implementar y en general consume mas recursos que otros modelos mas sencillos.

Se podría decir que es una herramienta indispensable para proyectos grandes que cuenten con un cierto nivel de riesgo, aunque esto no evita que se use para proyectos minúsculos si así se desea.

El framework USDP cuenta con muchas variantes, siendo RUP (Rational Unified Process) la mas famosa de ellas. Pero hay muchas mas, por ejemplo

  • Enterprice Unified Process
  • Open Unified Process
  • Agile Unified Process

Siendo las ultimas dos versiones mas ligeras del mismo modelo, con el fin de poderlos aplicar a proyectos y problemas menos exigentes y así reducir el nivel de trabajo.

Cabe resaltar que IBM cuenta con una herramienta llamada IBM Rational Software Architect Designer que ayuda a desarrolla y aplicar la metodología RUP. Y en su documento Rational Unified Process: Best Practices for Software development Teams definen el proceso RUP de la siguiente manera:

The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.

Aunque RUP no sea el unico proceso para implementar el USP, es sin lugar a dudas el que tiene mas documentación y herramientas con las cuales apoyarnos. Y si tu proyecto lo requiere seria una excelente opción para desarrollar y mantener tu software.