--------------------

/Capitulo 04: Clases/

-------------------
Las clases se pueden utilizar para representar cosas que sean software
,hardware o cosas puramente conceptuales.
Una clase es una abstraccion de las cosas que forman parte del
vocabulario.Una clase representa un conjunto de objetos.
La representacion grafica de las clases permite resaltar las partes
mas importantes de una abstraccion: su nombre, sus atributos y sus
operaciones.

Terminos y conceptos
Una clase es la descripcion de un conjunto de objetos que comparten
los mismos atributos, operaciones, relaciones y semantica.

*Nombres
Un nombre es una cadena de texto. Ese nombre solo se denomina nombre
simple; un nombre calificado consta del nombre de la clase precedido
por el nombre del PAQUETE en el que se encuentra.
NOTA: El nombre de una clase puede ser texto formado por cualquier
numero de letras, numeros y ciertos signos de puntuacion (excepto
signos como los DOS PUNTOS,que se utilizan para separar el nombre
de una clase y el del paquete que la contiene) y puede extenderse
a lo largo de varias lineas.
Nombre simple: Cliente Nombre calificado: java::awt::Rectangle

*Atributos
Un atributo es una propiedad de una clase identificada con un nombre,
que describe un rango de valores que pueden tomar las instancias de la
propiedad. Una clase puede tener cualquier numero de atributos o no
tener ninguno.
Un atributo es una abstraccion de un tipo de dato o estado que puede
incluir un objeto de la clase.
NOTA: Normalmente, se pone en mayusculas la primera letra de cada
palabra de un atributo, excepto la primera letra, como en nombre
o esMaestra.
Un atributo se puede especificar aun mas indicando su clase y quizas
un valor inicial por defecto o indicando si es de solo lectura o esta
compartido por todos los objetos de la clase.

*Operaciones
Una operacion es la implementacion de un servicio que puede ser reque
rido a cualquier objeto de la clase para que muestre un comportamiento.
Una clase puede tener cualquier numero de operaciones o ninguna. Se
puede especificar aun mas la implementacion de una operacion utilizando
una nota o utilizando un diagrama de actividades.
NOTA: normalmente el nombre de una operacion es un verbo corto o una
expresion verbal, que se pone en mayusculas la primera letra de cada
palabra en el nombre de una operacion excepto la primera letra,como
en mover o estaVacio.

Organizacion de atributos y operaciones

Se puede abreviar una clase, mostrando solo algunos o incluso ninguno
de sus atributos y operaciones. Un compartimiento vacio no significa
necesariamente que no haya operaciones o atributo, solo que se ha
decidido no mostrarlos. Se puede especificar explicitamente que hay
mas atributos o propiedades que los mostrados acabando la lista con
puntos suspensivos ("..."). Tambien se puede suprimir por completo
el compartimiento, en cuyo caso no se puede afirmar si hay atributos
u operaciones, o cuantos hay.
Para una mejor organizacion se pueden usar los ESTEREOTIPOS.

Responsabilidades
Es un contrato o una obligacion de una clase. Una clase puede tener
cualquier numero de responsabilidades, aunque en la practica, cada
clase bien estructurada tiene al menos una responsabilidad y a lo
sumo una pocas.NOTA: las responsabilidades son solo texto libre.
---------------------
|AgenteDeFraudes | Otras caracteristicas
|---------------------| Cuando se empieza a dise�ar la implementacion
|---------------------| de una clase, se necesita modelar su estructura
|---------------------| interna como un conjunto de partes conectadas.
|Responsabilidades | UML proporciona las CLASES ACTIVAS (para re-
|-determinar el ries- | presentar procesos e hilos) y clasificadores,
|go del pedido de | como los artefactos (para representar compo-
|un cliente | nentes software fisicos) y nodos (para repre-
--------------------- sentar dispositivos hardware).
En UML, hay sociedades de clases que forman colaboraciones y normal-
mente se representan en diagraman de clases.

Tecnicas comunes del modelado

*****************************
$$$ Modelado del vocabulario de un sistema
Para los usuarios, la mayoria de abstracciones las extraen de objetos
que ellos ya usan para describir su sistema. Tecnicas de encontrar estas
abstracciones: Tarjetas CRC y el analisis basado en casos de usos.
Para modelar el vocabulario de un sistema:
#Identificar aquellas cosas que utilizan los usuarios o programadores
para describir el problema o la solucion.
#Para cada abstraccion,hay que identificar un conjunto de responsabili-
dades.
#Hay que proporcionar los atributos y operaciones necesarios en cada
clase para cumplir esas responsabilidades.
Muchas de las clases que se encuentran tienden a agruparse en grupos
relacionados conceptual y semanticamente. En UML se pueden utilizar los
paquetes para modelar estos grupos de clases.
La mayoria de las abstracciones del vocabulario del sistema interactuan
entre si de forma dinamica.

$$$ Modelado de la distribucion de responsabilidades en un sistema

Es necesario asegurarse de que las abstracciones proporcionan un
conjunto equilibrado de responsabilidades. Si se abstraen clases
demasiado grandes, observaremos que los modelos son dificiles de cambiar
y no muy reutilizables. Si se abstraen clases demasiado peque�as, acaba-
remos con muchas mas abstracciones de las que se pueden manejar o com-
prender razonablemente. UML es util para este reparto de responsabilidades.
Para modelar la distribucion de responsabilidades en un sistema:
#Hay que identificar un conjunto de clases que colaboren entre si para
llevar a cabo algun comportamiento.
#Identificar un conjunto de responsabilidades para cada una de esas clases.
#Hay que mirar este conjunto de clases como un todo, DIVIDIR las clases
con demasiadas responsabilidades en abstracciones mas peque�as,fusionar
las clases peque�as con responsabilidades triviales en otras mayores, y
reubicar las responsabilidades para que cada abstraccion se mantenga
razonablemente coherente.
#Considerar la forma en que esas clases colaboran entre si, y redistribuir
sus responsabilidades adecuadamente.
$$$ Modelado de cosas que no son software
Para modelar las cosas que no son software:
#Hay que modelar la cosa que se esta abstrayendo como una clase.
#Si se quieren distinguir estas cosas de los bloques de construccion de
UML, hay que crear un nuevo bloque de construccion utilizando estereotipos.
#Si lo que se esta modelando es algun tipo de hardware que a su vez contiene
software, habria que plantearse modelarlo como un tipo de nodo.
NOTA: UML tiene como objetivo principal el modelado de sistemas con gran
cantidad de software, pero tambien puede ser bastante expresivo para
modelar sistemas de hardware.

$$$ Modelado de tipos primitivos

Para modelar tipos primitivos:
# Modelar la cosa que se esta abstrayendo como un tipo o una enumeracion,
que se representa como una clase con el estereotipo adecuado.
#Si se necesita especificar el rango de valores asociado al tipo, hay que
utilizar restricciones.
En UML se pueden modelar tipos o enumeraciones del mismo modo que las
clases, pero se marcan explicitamente mediante estereotipos.
Los enteros(representados por la clase Int) se modelan como tipos. Los
tipos enumerados como Boolean y Estado pueden modelarse como enumeraciones
con sus valores literales individuales listados en el compartimiento de
los atributos(aunque no son atributos).

Sugerencias y consejos
Una clase bien estructurada:
*Proporciona una abstraccion precisa.
*Contiene un peque�o conjunto bien definido de responsabilidades.
*Proporciona una clara distincion entre la especificacion de la abstraccion
y su implementacion.
Cuando se dibuje una clase en UML:
*Mostrar solo aquellas propiedades de la clase que sean importantes.
*Organizar las listas largas de atributos y operaciones, de acuerdo a su
categoria.
*Mostrar las clases relacionadas en el mismo diagrama de clases.

--------------------------------
/Capitulo 08: Diagrama de clases/
-------------------------------
Un diagrama de clases muestra un conjunto de clases, interfaces y colabo-
raciones, asi como sus relaciones.Estos se utilizan para modelar la
VISTA DE DISE�O ESTATICA DE UN SISTEMA, ademas son la base para un par de
diagramas relacionados: los diagramas de componentes y los diagramas de
despliegue. Los diagramas de clases son importantes para VISUALIZAR,
ESPECIFICAR Y DOCUMENTAR modelos estructurales asi como para construir
sistemas ejecutables,aplicando ingenieria inversa y directa.
Dada la fluidez del software, es posible definir los bloques de construccion
basicos desde cero.

Terminos y conceptos
&&& Propiedades comunes
Un diagrama de clases es un tipo especial de diagrama y comparte las pro-
piedades comunes al resto de los diagramas(nombre y contenido grafico).
&&& Contenido
*Clases
*Interfaces
*Relaciones de dependencia, generalizacion y asociacion
Tambien pueden contener notas, restricciones, paquetes o subsistemas.
A veces se colocaran instancias en los diagramas de clases, por si
son del tipo dinamico.
NOTA: Los diagramas de componentes y los diagramas de despliegue son
similares a los diagramas de clases, excepto que en lugar de clases
contienen componentes y nodos, respectivamente.
&&& Usos comunes
La vista de dise�o estatica soporta principalmente los requisitos funcio-
nales de un sistema, los servicios que el sistema debe proporcionar a
sus usuarios finales.Normalmente se utilizaran los diagramas de clases de
una de estas tres formas:
1. Para modelar el vocabulario de un sistema.
Decidir que abstracciones son parte del sistema y cuales caen fue-
fuera de sus limites.
2. Para modelar colaboraciones simples.
Una colaboracion es una sociedad de clases, interfaces y otros
elementos que colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de todos los elementos.
3. Para modelar un esquema logica de base de datos.
En muchos dominios se necesitara almacenar informacion persisten-
te en una base de datos relacional o en una base de datos orien-
tada a objetos. Se pueden modelar esquemas para estas bases de
datos mediante diagramas de clases.

Tecnicas comunes de modelado

----------------------------
$$$ Modelado de colaboraciones simples
Para modelar una colaboracion:
* Identificar los mecanismos que se quieren modelar.Un mecanismo represen-
ta una funcion o comportamiento de la parte del sistema que se esta
modelando.
*Para cada mecanismo, hay que identificar las clases, interfaces y otras
colaboraciones que participan en esta colaboracion.
*Usar escenarios para recorrer la interaccion de estos elementos.
*Comenzar obteniendo un reparto equilibrado de responsabilidades. Despues
con el tiempo, hay que convertir estas en atributos y operaciones concretos.

&&& Modelado de un esquema logico de base de datos

UML es apropiado para modelar esquemas logicos de bases de datos, asi como
bases de datos fisicas.
Los diagramas de clases de UML son un superconjunto de los diagramas
entidad-relacion (E-R). Mientras que los diagramas E-R clasicos se centran
solo en los datos, los diagramas de clases van un paso mas alla, pues
permiten el modelado del comportamiento. En la base de datos fisica,
estas operaciones logicas normalmente se convierten en disparados(triggers)
o procedimientos almacenados.
Para modelar un esquema:
*Identificar aquellas clases del modelo cuyo estado debe trascender el
tiempo de vida de las aplicaciones.
*Crear un diagrama de clases que contenga estas clases.
*Especificar los detalles de sus atributos y centrar la atencion en las
asociaciones que estructuran estas clases y en sus cardinalidades.
*Buscar patrones comunes que complican el dise�o fisico de la base de
datos tales como asocianes ciclicas y asociaciones uno a uno. Donde sea
necesario, deben crearse abstracciones intermedias para simplificar la
estructura logica.
*Para proporcionar una mejor separacion de intereses, las reglas de
negocio relativas a la manipulacion de conjuntos deberian encapsularse
en una capa por encima de estas clases persistentes.
*Donde sea posible, hay que usar herramientas que ayuden a transformar
un dise�o logico en un dise�o fisico.
NOTA: El dise�o logico de bases de datos cae fuera del alcance de este
libro
Hay muchas operaciones que se podrian considerar para estas dos clases
y para el resto, como consultar los prerrequisitos de un curso antes
de asignarle un estudiante. Estas son mas bien REGLAS DE NEGOCIO en vez
de operaciones para integridad de la base de datos.

Ingenieria directa e inversa

----------------------------
Recordar que el producto principal de un equipo de desarrollo es software,
no diagramas, por ello es importante que los modelos que se creen y las
implementaciones que se desplieguen se correspondan entre si, de forma que
se minimice o incluso se elimine el coste de mantener sincronizados los
modelos y las implementaciones.
Para algunos casos de UML, los modelos realizados nunca se corresponderan
con un codigo.Ejem: las personas o una pieza de hardware.
En la mayoria de casos los modelos creados se corresponderan con codigo.
LA INGENIERIA DIRECTA es el proceso de transformar un modelo en codigo
a traves de una correspondencia con un lenguaje de implementacion, produce
una perdida de informacion, porque los modelos son semanticamente mas
ricos que el codigo. Las caracteristicas estructurales como las colabora-
ciones y las caracteristicas de comportamiento pueden visualizarse
claramente en UML, pero no tanto en simple codigo fuente.
Para hacer ingenieria directa con un diagrama de clases:
*Identificar las reglas para la correspondencia al lenguaje o lenguajes
de implementacion elegidos.
*Segun la semantica de los lenguajes escogidos, quiza haya que restringir
el uso de ciertas caracteristicas de UML.
*Usar valores etiquetados para guiar las decisiones de implementaciones
en el lenguaje destino. Esto se puede hacer a nivel de clases individuales
si es necesario un control mas preciso o, a un nivel mayor como colabora-
ciones o paquetes.
*Usar herramientas que generen codigo.
LA INGENIERIA INVERSA es el proceso de transformar codigo en un modelo a
traves de una correspondencia con un lenguaje de programacion especifico,
produciendo un aluvion de informacion, parte de la cual esta a un nivel
de detalle mas bajo del que se necesita para construir modelos utiles.
Para hacer ingenieria inversa sobre un diagrama de clases:
*Hay que identificar las reglas para la correspondencia desde el lenguaje
o lenguajes de implementacion elegidos.
*Con una herramienta, hay que indicar el codigo sobre el que se desea
aplicar ingenieria inversa. Hay que usar la herramienta para generar
un nuevo modelo o modificar uno existente al que se le aplico ingenieria
directa previamente. La ingenieria inversa produce muchos modelos a par-
tir de un gran bloque de codigo.
*Con la herramienta, hay que crear un diagrama de clases inspeccionando
el modelo.
*La informacion de dise�o se puede a�adir manualmente al modelo para
expresar el objetivo del dise�o.

Sugerencias y consejos
Un diagrama de clases bien estructurado:
*Se centra en comunicar un aspecto de la vista de dise�o estatica de un
sistema.
*Contiene solo aquellos elementos que son esenciales para comprender ese
aspecto.
*Proporciona detalles de forma consistente con el nivel de abstraccion,
mostrando solo aquellos adornos esenciales.
Cuando se dibuje un diagrama de clases:
*Darle un nombre que comunique su proposito.
*Distribuir sus elementos para minimizar los cruces de lineas.
*Organizar esencialmente espacialmente de modo que los que esten cercanos
semanticamente tambien lo esten fisicamente.
*Usar notas y colores como se�ales visuales.
*Intentar no mostrar demasiados tipos de relaciones.

---------------------------------
/Capitulo 14: Diagrama de Objetos/
--------------------------------
Los diagramas de objetos modelan las instancias de los elementos existentes
en los diagramas de clases. Un diagrama de objetos muestra un conjunto de
objetos y sus relaciones en un modelo concreto.
Los diagramas de objetos se utilizan para modelar la vista de dise�o
estatica o la vista de procesos estatica de un sistema.
Los diagramas de objetos no solo son importantes para visualizar, especi-
ficar y documentar modelos estructurales, sino tambien para construir los
aspectos estaticos de sistemas a traves de ingenieria directa e inversa.
En todos los sistemas orientados a objetos, excepto en los mas simples,
existira una multitud de objetos,cada uno de los cuales mantiene una
relacion precisa con los demas. De hecho, cuando un sistema orientado
a objetos falla, no suele ser por un fallo en la logica, sino porque se
rompen conexiones entre objetos o por un estado no valido en objetos
individuales.
Los diagramas de interaccion se utilizan para ver los aspectos dinamicos
del sistema, y constan de instancias de estos bloques de construccion y
los mensajes enviados entre ellos. Un diagrama de objetos contiene un con-
junto de instancias de los elementos existentes en un diagrama de clases.
Por tanto, un diagrama de objetos expresa la parte estatica de una inte-
raccion, y consta de los objetos que colaboran, pero sin ninguno de los
mensajes que se envian entre ellos.

Terminos y conceptos
Un diagrama de objetos es un diagrama que representa un conjunto de
objetos y sus relaciones en un momento concreto. Graficamente, un
diagrama de objetos es una coleccion de nodos y arcos.
**Contenidos
-Objetos
-Enlaces
Tambien pueden contener notas y restricciones. A veces se colocaran clases
en los diagramas de objetos, especialmente cuando se quiera mostrar la clase
que hay detras de la instancia.

**Usos comunes
La vista de procesos estatica de un sistema, pero desde la perspectiva
de instancias reales o prototipicas; sustenta principalmente los requi-
sitos funcionales de un sistema(servicios a usuarios finales).
Un diagrama de objetos representa una escena estatica dentro de la his-
toria representada por un diagrama de interaccion. El comportamiento
dinamica y la ejecucion se pueden representar como una secuencia de
escenas.

Tecnicas comunes de modelado

$$$ Modelado de estructuras de objetos
Cuando se construye un diagrama de clases,de componentes o de despliegue,
solo muestran "lo que puede ser". Los diagramas de objetos son especial-
mente utiles para modelar estructuras de datos complejos. Al utilizar
diagramas de objetos solo se pueden mostrar significativamente conjuntos
interesantes de objetos concretos o prototipicos.
Para modelar una estructura de objetos:
*Hay que identificar el mecanismo que se quiere modelar.
*Hay que crear una colaboracion para describir un mecanismo.
*Para cada mecanismo, hay que identificar las clases, interfaces y otros
elementos.
*Considerar un escenario en el que intervenga este mecanismo. Congelar
ese escenario en un momento concreto, y representar cada objeto que par-
ticipe en el mecanismo.
*Mostrar el estado y los valores de los atributos de cada uno de esos
objetos, si son necesarios para comprender el escenario.
*Mostrar los enlaces entre esos objetos, que representaran instancias de
asociaciones entre ellos.

Ingenieria inversa
Hacer ingenieria inversa (creacion de un modelo a partir del codigo).Por
ejemplo, si se esta persiguiendo un enlace perdido, uno dibujara mental
o literalmente un diagrama de objetos de los objetos afectados, para ver
donde se invalida, en un momento dado, el estado de un objeto o su rela-
cion con otros objetos.
Para hacer ingenieria inversa con un diagrama de objetos:
*Elegir el objetivo al que se desea aplicar la ingenieria inversa.
*Detener la ejecucion en un determinado instante.
*Identificar el conjunto de objetos que colaboran en el contexto, y re-
presentarlos en un diagrama de objetos.
*Si es necesario para comprender la semantica, mostrar el estado de estos
objetos e identificar los enlaces entre estos objetos.
*Si el diagrama termina complicandose en exceso, se puede recortar, eli-
minando aquellos objetos que no sean pertinentes.Si es simple, hay que
expandir los vecinos de los objetos para mostrar el estado de cada objeto.

Sugerencias y consejos
Un diagrama de objetos bien estructurados:
*Se centra en comunicar un aspecto de la vista de dise�o estatica o la
vista de procesos estatica de un sistema.
*Representa una escena de la historia representada por un diagrama de
interaccion.
*Contiene solo aquellos elementos esenciales para comprender ese aspecto,
*Proporciona detalles de forma consistente con el nivel de abstraccion.
Cuando se dibuje un diagrama de objetos:
*Darle un nombre que comunique su proposito.
*Distribuir sus elementos para minimizar los cruces de lineas.
*Organizar sus elementos espacialmente.
*Usar notas y colores.
*Incluir los valores y estados de cada objeto.