Ted Mosby, architect

Bien, ya tenemos algunas buenas prácticas para resolver el problema de nuestra vecina y de nuestro amigo que tiene un ciber, ¿qué pasará cuando tengamos un problema real, uno de esos grandes y complejos que de sólo pensarlos ya se nos ha complicado más la vida? Bueno, para calmar esas ansias sobre qué pasara cuando tengamos que estar en esa situación han escrito este capítulo. Este capítulo en especial a mi parecer es uno de los principales pues toca muchos temas al mismo tiempo así que agárrate bien de tu silla que allá vamos.

Divide et impera

via GIPHY

¿Por qué nunca me habían dicho que la versión en latín de divide y vencerás sonaba más cool? Bueno, cómo sea, ya te han contado de esto cuando llevaste algoritmos y recursión, divide tu problema grande en otros más pequeños, ¿ahora qué? Pues al diferencia de tu clase de algoritmos donde no aprendiste nada, en este capítulo si que te dan pautas para dividir tu problema de una forma efectiva pues de incitan a dividir tu problema en muchísimas partes funcionales y trabajar en estas partes individualmente.

¿Cómo trabajar con ellas? Bueno, no hay mucho misterio, ya que tenemos nuestra caja de Diseño Orientado a Objetos medio llena tenemos que comenzar a aplicar estos principios. Esto lo harás con las partes funcionales pequeñas pero, ¿qué hay del gran problema? Venga, ¡si estás poniendo atención! Para tu problema grande primero tenemos que aplicar otras cosas antes de usar del todo nuestra caja.

La información es poder

via GIPHY

¿Cómo comenzar si no sabes ni siquiera de dónde partir? Este es el principal problema de aproximadamente el 80% de todas las personas que escriben código, bueno, esa estadística ha salido de mi imaginación pero no tengo ninguna duda acerca de que es cierta querer escribir código desde el principio y no detenerse ni siquiera 5 minutos a pensar qué demonios se tiene que hacer. Para hacer esta pausa y lograr obtener la información adecuada contamos con la siguientes conceptos:

• commonality: ¿A qué cosa que ya existe se parece tu sistema? El tener un punto de referencia siempre es un buen punto de partida.
• variability: es lo contrario a la característica de arriba, ¿a qué no se parece tu sistema? El tener claro a qué definitivamente no será tu sistema te hará tener una mejor perspectiva.

'It's Not a Bug, It's a Feature' 

via GIPHY

Características aquí, características allá, siempre nos han dicho que tenemos que tener claras estas si queremos que nuestro sistema haga exactamente lo que nuestro cliente quiere pero primero debemos de tener claro qué demonios es una característica. Una característica es una descripción a alto nivel de algo que hace nuestro sistema, espera... Eso se parece a un requerimiento, mira con la cara que me mira Konan ¿seguro que no me estás engañando? Pues se parece pero definitivamente no es lo mismo.

Una característica va más enfocado al cliente y por ende utiliza un lenguaje nada técnico mientras que los requerimientos van dirigidos a los desarrolladores, también sirve si lo ves como que una característica es el padre de los requerimientos pues una de estas se puede componer de múltiples requerimientos. Bien, ya sabemos la diferencia entre característica y requerimiento pero, ¿hay alguna herramienta que nos sirva para definir las características tal y como los requerimientos y los casos de uso? Ya se me hacía que no lo ibas a preguntar jamás, sí, sí la hay y que llaman diagramas de caso.

Diagramas de casos

De UML_diagrama_caso_de_uso.png: en:User:Poor Yorick derivative work: ApokalipsyS (talk) - UML_diagrama_caso_de_uso.png, CC BY-SA 3.0, Enlace

Un diagrama de caso es un dibujo hecho por mi hermano de 3 años un diagrama básico que te recuerda qué hace un sistema de manera general. Recuerda esa palabra, general, muy general. ¿ya lo olvidaste? General. Un diagrama de caso nunca será igual de detallado que un caso de uso porque no está hecho para eso pues se concentra en hacer una imagen completa de tu sistema y qué hará esto por los actores, ¿actores como Leonardo Dicaprio? No. Bueno, parece que estás un poco perdido.

Lo que está dentro del rectángulo es tu sistema y los óvalos son cosas que el actor hará con él. Como puedes observar, puede haber más de un actor y estos son ajenos al sistema por lo que estarán afuera, estos actores no siempre serán humanos pues también pueden ser animales o entidades inanimadas. La verdad es que no hay mucho misterio en estos diagramas, pero tenemos que hablar de cómo obtendrás lo que hay dentro de los óvalos.

Análisis de dominio

via GIPHY

Un análisis de dominio se centra en el proceso de identificar, recolectar, organizar y representar información relevante de un dominio basado en el estudio de sistemas e historias de desarrollo,  conocimiento de expertos en el tema y teoría bien documentada. En sí, se trata de que muevas el trasero y busques información acerca de lo que va tu sistema y no te quedes con lo que tu cliente te está contando. Así, sin más.

Hacer este análisis es súper necesario ya que, si bien no te tienes que convertir en un experto acerca de lo que va cada sistema que hagas a lo largo de tu carrera, si tienes que tener una buena perspectiva si quieres que tu sistema funcione. A lo largo de este artículo hemos visto muchos conceptos nuevos y espero que te sean de mucha utilidad cuando estés desarrollando tus sistemas.

 ¡Nos vemos a la vuelta!

Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.