Comenzaré con un diagrama de estados, este indica qué se está haciendo en un momento dado, puede ser un usuario haciendo una tarea, una tarea realizando procesos, un proceso realizando pasos. Con un diagrama de estados nos orientamos respecto a qué queremos lograr. Laborar sin un diagrama de estados es equivalente a dejar a la deriva al objetivo que queremos lograr.
Diseño Progresivo.
Normalmente utilizo un diagrama de estados "en dos pasadas" durante el desarrollo de una aplicación, lo pongo entre comillas porque no son estrictamente dos pasadas, sino varias, aunque de modo conceptual son dos. Todo en UML es así, progresivo, de lo mas grueso a lo mas fino y el análisis con ayuda de diagramas de estados no se salva.
Unificación
Los diagramas de estado van muy de la mano con los diagramas de casos de uso. Todo en UML va de la mano con todo. El objetivo es permitir un uso claro y firme de un proceso de negocio, visto desde diferentes puntos de vista. Un punto de vista puede ser las prestaciones que le damos al usuario de forma generalizada (diagramas de casos de uso), otro punto de vista puede ser cómo ese usuario hará los procesos en un momento dado (diagramas de estado), otro punto de vista sería cómo varias partes interactuan entre sí en un momento en el tiempo (diagramas de secuencia).
No, así no es.
Todos los diagramas en UML están conectados. Muchas veces se de personas o lideres de proyecto que obligan a sus desarrolladores a cumplir todos y cada uno de los casos de uso, tratándolos como si de un mapa detallado del proyecto se tratase. Podríamos muy bien comenzar con un diagrama de estados, uno de secuencia o uno de casos de uso. Normalmente cuando alguien "obliga" es porque no sabe o no conoce el uso verdadero de UML en un proyecto.
Un Ejemplo Concreto
Supongamos que quiero diseñar una aplicación web en la cual el usuario final va a realizar muchas actividades, va a crear contactos, explorar contactos, explorar documentos, subir fotografías, explorar las fotos.
La siguiente imagen muestra un caso real de un diagrama de estados que muestra la "navegabilidad" de un usuario frente al sistema. Cada "cajita" representa un estado. Cada una dice: "el usuario esta haciendo esto". Dependiendo del concepto que cada estado da entonces procedemos a ir a otro estado. No tiene sentido crear aplicaciones con un menú que da acceso a general todo el tiempo, el usuario final se confunde. El usuario debe tener acceso solo a aquello que le compete inmediatamente, en este diagrama abajo esa opción es representada por la letra "s" debajo de una flecha de asociación, quiere decir: "el usuario puede ir desde aquí a ...".
Issues, Diagramas Progresivos, Adaptación.
Verán que hay un set de anotaciones a la izquierda del diagrama (arriba), son "issues" (asuntos pendiente). Les recuerdo que este diagrama en la imagen es un caso real, recuerdo además que UML es progresivo. Hay otro diagrama que precede a éste y hay código hecho en consecuencia, por tanto el código desarrollado con ese anterior diagrama requiere algunos ajustes para adaptarse a este nuevo diagrama. Esto ultimo es importante de comprender.
Debido al concepto progresivo de UML vamos guiando el desarrollo con ayuda de diagramas, siempre existirá una mejor forma de hacer las cosas por tanto al diagrama anterior nos comparamos y vemos qué debe hacerse para continuar en el camino diseñado. Tal cual como cuando un piloto define un plan de vuelo, nunca será perfecto, pero si será predefinido, durante el vuelo hacemos ajustes de rumbo y mientras mas nos acercamos al aeropuerto destino mayor será el ajuste, hasta aterrizar.
Subestados y Casos de Uso
Cada cajita en el diagrama de arriba es un estado, es un momento en el tiempo del sistema. Según el caso de aplicabilidad del digrama. En este caso en donde el diagrama representa "la navegabilidad" entonces cada cajita define "qué esta haciendo el usuario en un momento dado".
Me centraré en el estado "MLS", el cual son las siglas de un componente del mundo Real Estate, de las inmobiliarias, este estado dice: "El usuario está seleccionando al inmueble que quiere vender". Seleccionar al inmueble es todo un caso de uso también. El usuario puede: buscar una propiedad en el sistema MLS, puede alterar algunos atributos como la dirección, la ciudad, el numero de calle etc, por esto insisto en que UML es una cohesión de diagramas, este sería el diagrama de casos de uso del estado "MLS":
Subestados y Casos de Uso: El Caso de Uso.
Este diagrama de casos de uso (imagen arriba) es el precedente al estado "MLS" dibujado en el diagrama de estados (la cajita etiquetada con "mls"). Este diagrama de caso de uso define qué va a hacer el usuario, no define cómo se va a comportar frente a otros casos, solo define qué va a hacer, es un grano muy grueso. Cada grafo dentro del caso de uso, por ejemplo "find a property" tiene unos pasos muy claros y gruesos que podrían bien dibujarse en un "diagrama de actividad del caso de uso". Estos pasos podrían ser:
Caso de uso: "Find a Property"
1. Presentar un formulario para introducir un numero.
2. Validar el numero.
3. Buscar el numero en la base de datos remota de propiedades a la venta.
4. obtener la información y traerla en forma de instancia (:inst) de una clase "MlsProperty".
Este caso de uso no hace nada mas que obtener la información remota de la casa que queremos buscar. La persistencia no existe al momento del modelado, no es relevante, lo principal es la funcionalidad del sistema frente a la entidad que lo use (humana o maquina).
Caso de uso: "Edit Attributes"
1. El usuario podrá visualizar los atributos de una casa guardada en el sistema para él.
2. Un formulario permitirá especificar nuevos datos y guardarlos (solo dios sabrá donde, no me importa en lo absoluto).
3. La información alterada será persistida para futura referencia, sin alterar la data remota.
Este caso de uso le da al usuario la potestad de obtener una copia de la información remota para su posterior alteración a medida de sus necesidades. No me interesa donde ser persista ni cómo, no es parte de esta etapa de modelado.
Subestados y Casos de Uso: El Subestado
Bien, ya sabemos que va a hacer un usuario, ahora necesitamos unas pantallas para llevarlo a cabo, nos ayudamos con un diagrama de estados que detallará al estado mayor: "MLS", cada estado puede tener subestados. El desarrollador de la aplicación incluso puede crear subestados de los subestados, pero esto no nos importa siempre y cuando el primer grado de subestados se cumpla.
El diagrama de subestados arriba de estas lineas es un caso real, disculpas por las anotaciones. Va de la mano con el diagrama de casos de uso, cumpliendo la premisa de "grano grueso, grano fino". Aqui vamos afinando el grano llevandolo a la realidad de la programación.
En este punto muchos estarán realizando la idea de que no tiene sentido usar tantas herramientas costosas en relación a consumo de procesador y memoria cuando en realidad una simple pizarra les sirve para todo, una pizarra es "un elemento social". Lo social importa a la hora de discutir un diseño de lo que sea, desde un nuevo submarino atómico hasta una simple aplicación web.
En el diagrama a continuación verán también unas pequeñas cajitas enumeradas (1,2,3) con letra roja, son puertos, puedes leer aquí para saber qué son los puertos y cómo se usan. Cada subestado puede ser alcanzado de varias vías diferentes como en el caso del subestado "2" (etiquetado como "2" en color azul arriba del cuadro), cada "llegada" al estado es un puerto, se hace algo diferente a la hora de aterrizar en un puerto.
Este pequeño code snippet muestra cómo manejo al subestado completo y sus puertos para dirigir al usuario a una parte específica dependiendo del puerto (los comentarios del codigo indican "PORT_1" y "PORT_2", según el caso (el "PORT_3" no es aplicado en el procedimiento de ejemplo sino en otro no publicado aqui),
private function _run($model, $user, $access_level, $mode){ // model: Transaction // access_level: 1:read 2:write if("auto" == $mode){ //look for present value in mls_numb if("" == $model->mls_mlsnumb){ // no value, launch the input form $this->handleInputForm($model, $user, $access_level); }else{ // value is present, let user alter it. // form is launched with $mlsdata readed from the transaction // PORT_1 $this->handleDataForm($model, $user, $access_level, $this->getMlsDataFromTransaction($model)); } }elseif(("manual" == $mode) || ("saveform" == $mode)){ // PORT_3 $this->handleDataForm($model, $user, $access_level, null); }elseif(("find" == $mode) || ("submitfind" == $mode)){ // let user find a different mls number $this->handleInputForm($model, $user, $access_level); } }
La presentación
No he hablado de la presentación, esa parte bonita en la que todos empiezan primero y que después no tienen idea de como hacer que funcione para cumplir las exigencias del cliente, creando como resultado código caótico, interdependiente y monolítico.
Esta es la presentación del sistema en cuestión:
1. El subestado "1"
2. El subestado "2"
3. El subestado: "3"
Los amantes de las herramientas gráficas "toderas" y diseñadores en línea, a los cuales su líder de proyecto les delega el modelado y todo lo demás junto en un grave acto técnico dirán: "que horrible, cómo puedo vender eso así de feo", quizá dirán: "si, así trabajan las personas esas de la vieja escuela, nada como lo moderno".
La responsabilidad del modelador es modelar y proveer funcionalidad, los desarrolladores llevan a cabo la funcionalidad, los diseñadores toman esta información con formato html y ahora aplicarán estilos, en este caso CSS Customization. Eso si, la responsabilidad del desarrollador y su técnica harán que el diseñador CSS pueda entender el formato y así poder dar un buen tono a la aplicación. Harina de otro costal.
Podrán observar la simpleza del diseño html, es a propósito, permite hacer que el sistema "quepa" en una pantalla móvil, tiene solo lo necesariamente estricto para funcionar, lo que el usuario no entrenado debe usar y nada mas.
No hay comentarios:
Publicar un comentario