Descubriendo clases asociativas. Modelo del Dominio. Edición 2019

Indice

Notas del autor 1

Tipos de objetos asociativos. Clases asociativas. 1

Introducción 1

Descubriendo clases asociativas 3

Desde atributos 3

Ejemplos 3

Ejemplo 1. Compra Repuestos 3

Ejemplo 2. Comentarios en noticias 4

Ejemplo 3. Inscripción 5

A partir de ciclos de vida de asociaciones 6

Síntomas para pensar... 7

Errores comunes 7

Historial de versiones 8

Notas del autor

Este apunte asume que el lector conoce la idea o concepto de tipos de objeto asociativos y ha
tenido algun tipo de experiencia básica en el uso de tipos de objetos asociativos o clases asociativas.

Tipos de objetos asociativos. Clases asociativas.

Introducción

Dentro del universo del modelo del dominio, existen un gran número de asociaciones distintas de las
asociaciones binarias o asociaciones "normales". Una de ellas, es la clase asociativas o tipo de
objeto asociativo.

Las clases asociativas ( o tipos de objetos asociativos) son clases y asociaciones a la vez. Suele ser
muy difícil darse cuenta de su presencia en las primeras iteraciones del desarrollo de un modelo
conceptual; pero a no desesperar, la experiencia ayuda a detectarlas más rápido.

La intención primaria para distinguir una clase asociativa es el hecho de la información que brinda al
lector.

A continuación, presentaré un ejemplo de tipo de objeto asociativo y su “equivalente” con
asociaciones binarias (o binarizadas).

Caso 1 de ejemplo

Un cliente realiza la solicitud de un servicio que ofrece la organización. Esta solicitud se conserva
para posteriores requerimientos de información. Veamos los diferentes modelos

Ejemplo 1.a Asociaciones y tipos de objeto asociativo

Ejemplo 1.b. Asociaciones binarizadas

Observe que:
la lectura con la clase asociativa es más robusta, ya que, si hubiera más asociaciones,

el lector no entendería que las asociaciones del ejemplo 1.b se leen en conjunto

con las clases.cuando se establece la asociación, se crea un objeto de la clase asociativa y además,

cuando se destruye un objeto, se pierde la asociación.

la existencia de los objetos de la clase asociativa depende de la existencia previa de los objetos de

las clases con los que se asocia, Estos objetos deben existir en todas las clases que participan de la

asociación del tipo de objeto asociativa.

De todos modos, las clases asociativas son fácilmente descubiertas cuando el analista tiene cierta
experiencia, por lo que también es sano, que Ud. no se torture y deje que la clase asociativa clame
por aparecer en el modelo. Nota: suelen aparecer más de un clase asociativa en un modelo real.

Aquí van algunas ideas para descubrirlas.

Descubriendo clases asociativas 

Desde atributos

Es posible que al principio no lo veas, excepto que sea casual; pero cuando comenzás a definir
atributos comienzan a visualizarse las clases asociativas. En general, primero se detecta la
asociación y luego, con los atributos se vislumbra la clase.

Ejemplos

Aquí se presentan algunos casos, pero ojo no todos derivan en clases asociativas.

Ejemplo 1. Compra Repuestos

Estamos trabajando en el modelo del dominio de un Casa de repuestos.

Un cliente compra repuestos. Un repuesto es comprado por ninguno, 1 o más clientes. El modelo del
dominio en cuestión resulta tan sencillo como se describe a continuación:

Ampliemos un poco el problema, resulta que existe un requerimiento que dice que el sistema debe
informar las compras realizadas por un cliente, cuando el director de compras lo solicite. Pensemos
el DD:

e. Sol_Cliente = CUIL

s. Compras_Cliente = datos_cliente(e) + 1{ fecha_compra + 1 {nombre-repuesto + cantidad }n}n

¿Si el modelo del dominio representa la memoria, dónde ubicaría los datos de la estructura
mencionada, la fecha-compra, nombre-repuesto y cantidad?

Recuerde que las asociaciones no pueden recordar atributo...piense.

El dato nombre-repuesto es una atributo del repuesto, pero: ¿y la fecha de compra?¿y la cantidad?
¿Son características del repuesto, o del cliente, o no corresponde a ninguno de los dos?

La conclusión es que no tiene un mejor lugar, pero son datos de la compra, pero la compra es una
asociación. Por lo que ahí tenemos la punta de la presencia de una clase-asociación, o bien, una
clase asociativa.

Ejemplo 2. Comentarios en noticias

Nuestro nuevo contexto es un diario digital. Una empresa gráfica estaba en el negocio de los
impresos, pero ahora es totalmente digital. Este hecho permite cumplir con una meta de la
organización, en donde el lector puede participar interactuando con comentarios en las noticias.

Digamos que un lector lee noticias. Un lector comenta noticias. 

¿Dónde ubicaría el comentario?

Voy a pensar en dos situaciones: 

1. No se quien comenta pero si sobre cuál noticia y que se comenta.
2. Se quién hace el comentario, cuál es el comentario y sobre cuál noticia.

Observe que la solución “a” no necesita una nueva clase, pero en cambio la segunda si.

Solución a

Solución b

Ejemplo 3. Inscripción

Ahora estamos en una institución educativa. Resulta que estamos pensando un sistema que permita
que el alumno se inscriba en las asignaturas. Simplemente eso, no la compliquemos más.

Ahora supongamos, que necesitamos saber cuando se produjo la inscripción para saber cuántos
anotados hay.

Obvio que necesito la fecha de inscripción. Observe que este atributo debe ser alojado en la
asociación, pero no es posible por ser asociación, entonces lo transformamos en clase asociativa.

Hasta aquí descubrimos clases asociativas a partir de la presencia de atributos.

A partir de ciclos de vida de asociaciones

Uno puede imaginar que se crea una asociación entre 2 o más objetos, entonces nace una
asociación. Si la asociación también es clase, entonces cuando nace la asociación nace al menos un
objeto que se asocia con los objetos de las otras clases. Así mismo, cuando elimino un objeto
también estoy eliminando la asociación  que los une con los objetos de las otras clases.

Los objetos del tipo asociativo están asociados al menos a 2 objetos distintos. No existe un objeto
del tipo asociativo en donde participa un solo objeto.

Un ciclo de vida de un objeto refiere al momento en que se crea un objeto  (nacimiento), su
modificación en el tiempo (evolución o crecimiento) y su destrucción o eliminación (muerte).

Un alumno hace inscripción de asignatura.

La asignatura tiene un ciclo de vida. Similar el alumno, pero qué pasa con la inscripción.

La inscripción surgió cuando quise decir algo entre alumno y asignatura, y solo sobrevivirá mientras
me interese lo que puedo decir.

Si no me interesa más lo que tengo que decir entre asignatura y alumno se tendrá que destruir la
inscripción. Luego de destruir la inscripción el alumno sigue existiendo y la asignatura también, pero
no lo que puedo decir entre ambas.

Ahora me pregunto: puedo tener una inscripción habiendo destruido su asignatura, o a su alumno.

Respuesta: NOOOOOOOOOOOOOOO

Conclusión: Inscripción es asociativo de asignatura y alumno...GRRRRR.

Síntomas para pensar...

Cuando se habla de síntomas (señal o signo de que una cosa está ocurriendo o va a ocurrir), no
implica necesariamente enfermedad. Por lo que ahora te propongo una situación especial donde se
presentan síntomas de presencia de clases asociativas. Esto es, cuando existen asociaciones cuya
multiplicidad en ambos extremos de la asociación es *, entonces alerta, puede haber presencia de
una clase asociativa. 

Errores comunes

1. Una clase asociativa es parte (o asociativa) de dos asociaciones distintas.

2. Una clase es asociativa de una única clase

3. .Hacer asociativa una clase que dio origen a otra que es asociativa y esta última clase

asociativa participa de la asociación. WTF?

Historial de versiones

Fecha	Versión	Autor	Descripción
Julio-2019	1.03	ALRO	Completado de introducción. Agregado de caso 1. Agregado de errores comunes
Marzo-2019	1.02	ALRO	Mejora de descripción de ejemplos. Armado de ejercicios relacionados para ampliación de práctica.
Junio-2018	1.01	ALRO	Revisión de texto, adaptación de encabezados y pie de página. Agregado de historial de versiones
Mayo-2016	1.00	ALRO	Primera versión

Modelo del Dominio. El factor X.

Sin dar vueltas, un modelo del dominio es un representación gráfica de los objetos del negocio o sistema, sus relaciones y de las propiedades de estos.

Suele pasar por varias fases de evolución y desarrollo. En general, los profesionales de sistemas lo utilizan para modelar la primera memoria del sistema de información desde la nada o el caos, también suele ser utilizado para modelar los componentes del software que se desarrolla a partir del sistema de información.
El enfoque que se trabajará aquí es el que corresponde al modelado de la memoria.

Cuando se comienza un análisis, y sobre todo cuando no existe experiencia previa, puede resultar caótico comprender y desarrollar la memoria de un sistema de información. El modelo del dominio te ayudará descompactar el caos y armar las primeras bases de la memoria del sistema de información.

Para armar un modelo del dominio se necesitan encontrar objetos y la mejor manera de ir por los objetos es encontrando los sustantivos.

Importante: no todos los sustantivos encontrados sobrevivirán, tenelo muy presente.

Las reglas de negocio son las que, en primera instancia, bosquejan el modelo, y es muy importante que sean las reglas, pues resultan ser uno de los elementos mas fuertes y más restrictivos dentro del sistema que se estudia. Si la regla se mantiene, la parte del modelo que refiere a la regla se sostiene.
Las reglas en general también son proveedoras de asociaciones y de atributos. Están ahí. Se tienen que saber aprovechar.

Ejemplo
RN001: una luna gira alrededor de un planeta.
RN002: Cada luna tiene un diámetro en kilómetros.

Ambas reglas colaboran, RN001 crea 2 clases y una asociación. La regla RN002 es proveedora de un atributo.

Los requerimientos también ayudan en el modelo de dominio. De hecho también gobiernan al modelado del modelo del Dominio

Ejemplo
El sistema debe mostrar el porcentaje de diámetro entre una luna y su planeta. Resulta que el porcentaje es un cálculo (otra regla), porcentaje de diámetro de luna = diam luna / diam planeta.

El modelo del dominio es el más sensible de todos los modelos del sistema de información es impactado por cualquier omisión, olvido o error.

Antes comentamos que las asociaciones surgen de reglas, bueno no son las únicas, lamento decirlo tan en frío, pero los requerimientos también pueden proveer de asociaciones. Quizás no siempre tan directamente. 

Ejemplo
Listar los proveedores de una determinada ciudad. Esto debería implicar que entre las clases proveedor y ciudad debe existir un camino de enlaces que permite encontrar las ciudades de los proveedores ( o al revés). el requerimiento sugiere asociaciones.

Esta historia continuará

¿Cuándo termina el análisis de un sistema de información?

Una de las preguntas más comunes tiene que ver con poder responder cuando una fase se ha cumplimentado en un ciclo de desarrollo de un producto de software. 
Suele ser común que la respuesta no sea única y cuando hacemos la pregunta:
¿Cuándo termina el análisis de un sistema de información?
No resulta sencillo dar respuesta, pues depende de algunos factores. 

Requerimientos estables
El primero y más importante es haber logrado estabilizar los requerimientos del sistema con el usuario. Una tarea que no siempre resulta sencilla.

Lograr la consistencia del modelo
A pesar de haber logrado el modelo de análisis, el analista tiene que asegurar por lo menos, que hay consistencia técnica en el modelo planteado.
Esto es, que no falten requerimientos menores, que las reglas que se plantean se respeten, que la idea de solución cierre como un todo. 
Aquí se cruzan las decisiones tomadas en los diferentes modelos: Ejemplo chequear que lo que hace el sistema sea posible de acuerdo a la memoria modelada, que la memoria modelada se integre con la información que el sistema debe producir, que se encuentren todos los requerimientos que permiten mover los estados de cada objeto, entre otras. Nota: hay más de lo que uno piensa.

Nivel de detalle adecuado
En más de una ocasión se logró lo anterior, pero cuando pasa la especificación del analisis al diseño o la programación (debería primero pasar al diseño...:)); encontramos que nuestros sucesores requieren aclaraciones. Estas aclaraciones pueden resultar de una documentación pobre o incompleta, cosas que no son lo mismo.
Si el analista recibe preguntas continuamente de sus sucesores, entonces el análisis no ha terminado.

¿Qué es ser un analista de un sistema de información?

Realizar un análisis de un sistema de información es estudiar, investigar, organizar y documentar un sistema de información.

El analista debe prepararse para descubrir lo cubierto. No es un dibujante y no es un documentador, es  un comprendedor.

No copia; crea, sugiere, define y expone un sistema subyacente en una organización o negocio.

El analista de hoy recomienda e incorpora requerimientos que el usuario aún no visualiza; por lo menos los expone, luego el usuario tomará la decisión sobre si se quedan o se van. Casi siempre se quedan.

Algunos creen y es un pensamiento muy facilista que un analista tiene por objetivo documentar. Me gusta pensar que el analista deja pruebas de lo acontencido para el resto de los profesionales y del negocio respecto de los descubrimientos realizados.

El analista construye y deconstruye a la organización a partir de datos e información. Libera en su mente una sustancia llamada asociación que amalgama y teje redes entre los datos, los procesos y la información.

El analista abre los portales de un universo oculto y lo expone. Lo manifiesta. El analista, metafóricamente hablando, es un explorador de una dimensión no visible para el común de la gente.

Juntando pruebas para estimar el esfuerzo

Desde el comienzo cualquier oráculo (lease libro, incluye libros electrónicos) dirá que la estimación es una aproximación. Con esto básicamente todos los autores se lavan las manos e introducen alguno de los riesgos siguientes: subestimar o sobreestimar el esfuerzo de un proyecto de software. Estos son riesgos gemelos que nunca se verán (claro, cuando uno se presenta el otro no lo hace). 
Al estimar ya se introducen los 2 riesgos, pero uno solo se materializará. La única certeza es que uno de los 2 se hace presente. Nunca, pero nunca estimarás y concidirá con la realidad. JAMÁS. 
Superada esa necesidad de ser perfecto, como todo informático, alcanzarás el paraíso, aunque sea mientras estimás.
Lo único que podés hacer es reducir la incertidumbre, para ello debes hacer historia. Y todos sabemos que la historia se recuerda si se registra. Entonces lo que debes hacer es:

1.  Registrar la estimación, registrar los requerimientos que se estiman, los supuestos y las fuentes.
2. Monitorear tu proyecto. Hacer un registro de las circunstancias, hechos e impresiones detectadas.  Hacé un bitácora, si, una bitacora, como la de la película (film) de viaje a las estrellas.
3. Registrar el trabajo real
4. Llevar adelante un lecciones aprendidas o bien, una restrospectiva del proyecto.

Con loselementos mencionados juntarás la prueba que avalará tus decisiones.

Las pruebas según el CMMI: (esto es una visión totalmente personal, no está escrito en CMMI)

1. Nivel 1. Inicial. Arranco y dejo. Comienzo y abandono. Resultado: material incompleto. Moraleja: perdiste el tiempo; pero aprenderás. Aprenderás que así no funciona.
2. Nivel 2: generás tu historia, pero como lo haces a tu modo. Resultará útil solo para ti, pero  poco utilizada para otros. Te vuelves cada vez menos aproximado, pero nunca serás certero. Habrá quienes te crean y quienes te lean. Resultado: Tu sabes la verdad. Los desvíos son menos que en otros tiempos. Ups de repente tengo capacidades especiales (el poder X de estimar). Ojo hay otros heroes que juegan igual.
3. Nivel 3. La organización se preocupa y ocupa por cumplir los pasos mediante un mecanismo uniforme. Los datos ahora son comparables. Hay aprendizaje organizacional.
4. Nivel 4. Hay indicadores que regulan a la estimación. La organización cree en esos indicadores. Quien se corre de los indicadores es un disidente.
5. Nivel 5. Lo dejo a tu criterio.

Conclusión 
Estimar es una experiencia unica para quien cumpla con esa función, pero debe procurar aprender de sus errores o falsas visiones. Eso lo mejorará radicalmente como profesional. Los pasos son fundamentales para demostrar que soy serio al momento de hacer mi trabajo.

¿Cuál requerimiento analizo primero?

No resulta fácil distribuir el trabajo del análisis, y esto es por varias razones. 
La razón que vamos a trabajar aquí tiene que ver con las dependencias entre los requerimientos. Supóngase que tiene 10 casos de uso de usuario (no historias de usuario, hablo de casos de uso 😡) y el análisis lo tiene que distribuir entre 2 analistas o más.¿Cuáles son los casos que asigna a un analista y cuáles a otros?¿ Pueden comenzar los analistas a trabajar en paralelo?¿Debe haber una coordinación?

Para la explicación voy a plantear un ejemplo, pues transcribir el enunciado lo haría muy pesado. Estimado lector vas a tener que creerme que es así

El ejemplo trata de un sistema de información para cumplir con la meta de Realizar giras de álbumes de cantantes que los promocionan.
La matriz de dependencias de requerimientos que se plantea ( y no puede discutirse) es la siguiente:

		1.01	1.02	1.03	1.04
1.01	Definir Gira	---
1.02	Confirmar Gira	Si	---
1.03	Cerrar Gira	Si		---
1.04	Cerrar Presentación				---

¿Cómo se lee?
un cambio en el caso de uso de 1.03 afecta o impacta al caso de uso 1.01. Nota: recuerde que un caso de uso es un conjunto de requerimientos, principalmente funcionales)

Sin importar cuantos analistas hay, con la matriz de dependencias se puede evidenciar que los análisis de los casos de uso no son paralelos. Si se analiza el caso de uso 1.01, luego cuando se analice el caso de uso 1.03, el caso de uso 1.01 se modificará. 
Entonces está solución no aplica:

mientras que esta solución si:

Conclusión
La segunda programación es más realista y factible. Esto es independientemente de los recursos que se asignen.
Falta trabajar un poco más en la programación, pero esta segunda opción sin dudarlo es mejor que la primera.