Divide y vencerás: guía rápida para software monstruo (o del tamaño del ego de un ingeniero)

Imaginemos un caso: tenemos un problema al cual podemos darle solución mediante software. ¿El inconveniente? El problema y la solución son exageradamente grandes para resolverlo por métodos Orientados a Objetos tradicionales. Empezamos entonces con una crisis. ¿Qué debemos hacer? ¿Cómo debemos modelar? Bueno, aquí en el consultorio del Doctor Profesor Alexis Freud ¡tenemos la solución!

GRSM: Guía rápida para software monstruo

No vamos a construir un castillo de un solo golpe, vamos a construir habitaciones, cocinas, baños y patios, siempre paso por paso.

architecture bay building castle
Photo by Pixabay on Pexels.com

Si el problema pareciera exceder nuestras capacidades, debemos entonces tomar una estrategia que exceda las capacidades del problema, o al menos que lo debilite. Lo mas sencillo es Divide y vencerás. ¿Qué pasa si un problema del tamaño del mundo lo dividimos en continentes? ¿Y si esos continentes los separamos en países? ¿Y esos países los separamos en regiones? ¿Y si esas regiones las separamos en ciudades? ¿Y si esas ciudades las separamos en vecindarios? Es mucho más fácil administrar un vecindario que administrar un planeta completo. Esto es nuestra propuesta de GRSM.

La guía es bastante sencilla:

Teniendo un problema gigante:

  1. Descripción de problema.
  2. Profundización.
  3. Diagramas básicos.
  4. Análisis.
  5. División.
  6. Principios Orientado a Objetos.
  7. Para cada elemento del paso 5, aplicar los pasos 1-6.

¿Qué significa todo esto? Lo veremos a continuación, pero antes, describiremos el problema que trataremos:

Problema

El señor Juan llega a pedirnos ayuda. Necesita de un programa que administre todo lo necesario para su universidad, llamada Universidad Privada de Freud (UPF), desde la entrada de un alumno hasta su salida, los profesores y personal de apoyo.


Descripción de problema

man making pizza dough
Photo by Fancycrave.com on Pexels.com

En esta fase de nuestra GSRM vamos a describir el problema de una forma sencilla: escribimos lo que el cliente necesite en no más de una página. Parece poco, ¿no? Pues el objetivo es que el cliente y el programador hablen el mismo idioma en una descripción tan poco detallada que nos pueda mostrar apenas los puntos más elementales de nuestro problema. Es como si nos piden preparar una pizza, pero sin decirnos los ingredientes, solo con las preferencias del cliente: “me gustan las pizzas dulces”, “me gusta que tenga muchos ingredientes”. En esta fase solo vamos a preparar la masa.

UPF

Hablamos con el señor Juan y nos dió una visión más detallada de lo que necesita:

Queremos que este programa nos sirva de auxiliar para la administración de la universidad, pero lo suficientemente sencillo para que cualquiera de nuestros empleados y alumnos puedan utilizarlo para ver o introducir información. El programa se encargará de hacer de todo. En particular:

  • Tener un historial por alumno.
  • Mostrar calificaciones de los alumnos.
  • Administrar pagos de colegiaturas.
  • Administrar sueldos de profesores, personal administrativo y personal de apoyo (limpieza, alimentación, cuidado de instalaciones y software).
  • Administrar horarios de clases y aulas.
  • Administrar actividades extracurriculares (deportivas y culturales).

Ya tenemos una visión más concreta de lo que nos están pidiendo. Aún no tenemos ni idea de qué es lo que haremos, pero tenemos un excelente punto de inicio.


Profundización

variety of vegetables
Photo by Adonyi Gábor on Pexels.com

En esta fase debemos comprender completamente la estuctura que necesitaremos. Utilizaremos la información de la fase de descripción para entender mejor el problema.

  • ¿Qué nos pide nuestro clietne?
  • ¿Qué necesidades debe satisfacer el programa?
  • ¿Cuales son sus funcionalidades principales?

Como siempre, debemos hacerlo con el objetivo de continuar entendiendonos con el cliente. Al cliente no le interesa ver diagramas de clases ni métodos, el cliente queire, antes que nada, entender que es lo que construiremos para el, por lo que debemos profundizar en la descripción tan general que tenermos anteriormente. En otras palabras y siguiendo el ejemplo de la pizza, ahora analizaremos el gusto del cliente para entender los ingredientes que podrían gustarle.

UPF

De acuerdo, ya sabes que es lo que necesitamos hacer. Tenemos aquí nuestra lista:

  • Tener un historial por alumno.
  • Mostrar calificaciones de los alumnos.
  • Administrar pagos de colegiaturas.
  • Administrar sueldos de profesores, personal administrativo y personal de apoyo (limpieza, alimentación, cuidado de instalaciones y software).
  • Administrar horarios de clases y aulas.
  • Administrar actividades extracurriculares (deportivas y culturales).

Pero ahora debemos analizar cada uno de estos puntos generales de manera más especifica. No solo queremos que nuestra solución administre y esas cosas, también sería bastante acertado que los alumnos, profesores y personal de apoyo puedan acceder a su información. Ver su sueldo, ver sus horarios, etc. Además, queremos que alumnos y profesores puedan inscribirse a actividades extracurriculares y clases, por lo que debemos crear un sistema de inscripciones.


Diagramas básicos

shallow focus photography of several pizzas
Photo by Narda Yescas on Pexels.com

¡Excelente! Ya tenemos los ingredientes que le pueden gustar al cliente. Ya tenemos la masa que quizá vayamos a utilizar, ahora hay que diseñar una posible pizza.

-Doctor Profesor Alexis Freud-

Ahora es tiempo de empezar a hacer diagramas. Podemos utilizar todos los diagramas que sabemos utilizar (o incluso encontrar nuevos). Debemos considerar que en una primera etapa vamos a mostrarle al cliente una idea base, un plano del programa, por lo que nuestro modelo deberá ser básico y utilizar un lenguaje común, nada de palabras técnicas. En etapas posteriores, ya podremos hacer diagramas de clase, métodos y esas cosas, pero por ahora un diagrama de caso de uso será suficiente.

UPF

Blank Diagram

 


Análisis

pizza in oven
Photo by Andru00e9 Beltrame on Pexels.com

Estamos a nada de meter la pizza al horno. ¿Ya esta lista? ¿Nuestro diagrama de pizza nos permite darle a nuestro cliente la pizza perfecta? Bueno, esas son preguntas que se deben responder en la fase de análisis. Mientras más conozcamos nuiestro problema, mejor podremos dar soluciones acertadas a el.

En la fase de análisis vamos a concretar cualquier cosa que nos haya quedado fuera en todas las fases anteriores. ¿Qué nos perdimos? ¿Qué funcionalidad no modelamos? ¿Qué nos hace falta para completar nuestro modelo de programa? Haciendo un buen análisis, nuestra siguiente fase será pan comido.

UPF

En el paso anterior tenemos un pequeño diagrama de caso de uso.

  • ¿Falta agregar algo? ¿Qué cosa/cosas?
  • ¿Es suficiente tener un solo usuario?
  • ¿El caso modela todo lo que nuestro programa debe hacer?

El diagrama nos permitirá hacernos estas preguntas desde antes de escribir una sola línea de código. Es fácil darse cuenta que no podemos tener solo un “usuario”, más bien deberíamos tener un “alumno”, un “profesor”, “una persona de apoyo” para poder darle funcionalidad a cada una de las actividades que nos piden. Además, en el diagrama podemos agregar más tareas con suma facilidad.


División

Adelante, ya teníamos nuestra pizza lista para prepararla, pero ¿qué haremos realmente? Hasta ahora solo hemos hecho diseños de pizza, hemos pensado en algunos ingredientes, y no parece suficiente para darle la pizza perfecta, entonces toca divir tareas. Ahora vamos a crear la pizza desde diferentes perspectivas que analizarán preferencias específicas del cliente: analizaremos la masa que debe llevar, los ingredientes dulces, los ingredientes salados, la salsa perfecta, la orilla y los quesos. ¿Qué significa? Es más fácil saber que tipo de masa desea el cliente que saber que tipo de pizza quiere el cliente. Vamos a atacar el problema desde todas las perspectivas posibles, por lo que delegaremos tareas a diferentes áreas. ¿De qué se compone a grandes razgos nuestro problema específico?

Visto de otra manera: debemos diseñar un auto, pero es más fácil que un grupo de personas trabaje en el motor, otro en la carrocería y diseño, otro en las llantas… Algo así:

Departamentos de diseño de auto:

  • Motor
  • Transmisión
  • Llantas
  • Diseño interior
  • Diseño exterior

De esta manera, solo tendremos que preocuparnos por una pequeña parte a la vez, no todo al mismo tiempo (que es difícil).

UPF

Estamos listos para repartir las tareas. Tenemos diferentes tareas dentro de nuestro programa universitario:

  • Alumnos:
    • Consultan calificaciones
    • Se inscriben a actividades extracurriculares
    • Se inscriben a clases
    • Pagan colegiaturas
  • Profesores
    • Ponen calificaciones
    • Ofrecen clases
    • Reciben sueldo

Aunque podriamos separarlo también de otro modo:

  • Administrador de universidad
    • Parte económica (sueldos y colegiatura)
    • Parte académica (clases, extracurriculares, calificaciones)
    • Parte de inscripciones
    • Parte informativa (historial de alumnos, información de profesores)

No hay una sola manera de dividir las tareas, siempre dependerá del análisis previo.


Principios Orientados a Objetos

Esta parte es fácil y opcional. Si conocemos los principios básicos del paradigma Orientado a Objetos, entoces podemos modelar las nuevas partes aplicando estos principios. Si no los conocemos, no pasa nada, podemos seguir modelando sin problema, aunque podemos dejar fuera muchass consideraciones que sí que se toman en el paradigma orientado a objetos.


Repetición

Finalmente llegamos al final. ¿O no? Pues apenas vamos iniciando. Queremos resolver un problema gigante, ¿no es así? Entonces vamos a analizar lo que serán nuestros nuevos problemas gigantes. Ya dividimos nuestro problema gigante, ahora cada una de esas particiones debe ser descrita, modelada y analizada como problema por separado, es decir, vamos a aplicar todo lo que hemos visto hasta aqui para todos los nuevos subproblemas.


Por ahora, esto ha sido todo. No queda más que comenzar a resolver esos problemas que resuelven las grandes empresas desde nuestro cómodo sillón o escritorio.

Créditos

McLaughlin B., Pollice G. & West, D. (2007). Head First to Object Oriented Analysis and Design. United States of America: O’Reilly Media.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s