Programación de Aplicaciones
Edición 2009

Informe del
Modelo de Diseño

Grupo X	
Integrantes	
		
Nombre1	CI: 1.111.111-1	
Nombre2	CI: 1.111.111-1	
Nombre3	CI: 1.111.111-1	
Nombre4	CI: 1.111.111-1	
Nombre5	CI: 1.111.111-1	

Docente:	Nombre Docente	

Índice
Indice	3
1	Introducción	4
1.1	Propósito	4
1.2	Alcance	4
1.3	Estructura del Documento	4
2	Organización Lógica	4
3	Realización de Casos de Uso	5
3.1	Colaboración 1	5
3.1.1	Estructura	5
3.1.2	Interacciones	6
3.1.2.1	Diagramas de colaboración de la operación 1	6
3.1.3	Design Patterns	7
3.1.3.1	Design Pattern 1	7
4	Criterios Generales	7

1	Introducción
1.1	Propósito
El propósito de este documento es brindar una descripción general del Modelo de Diseño.
1.2	Alcance
El informe del Modelo de Diseño presenta una abstracción de la solución lógica al problema. Incluye las colaboraciones que realizan cada uno de los casos de uso del Modelo de Casos de Uso.
1.3	Estructura del Documento
El documento está dividido en tres secciones. La segunda sección presenta la organización lógica del sistema en paquetes de diseño. La tercera sección presenta las colaboraciones con la realización de los casos de uso incluidos en el Modelo de Casos de Uso. Por último, la cuarta sección presenta los criterios generales adoptados para el diseño de las colaboraciones.

A lo largo de esta plantilla se encuentran comentarios y ejemplos acerca del contenido del documento a elaborar a partir de ésta. Éstos se encuentran indicados, al igual que este párrafo, por una línea a lo largo de su borde izquierdo. Estas secciones deben ser eliminadas de la versión final del documento.
2	Organización Lógica
A los efectos de organizar la capa lógica se definen paquetes de diseño. Cada paquete de diseño puede contener clases de diseño y otros paquetes de diseño. En esta sección se incluyen los paquetes de diseño existentes y las clases incluidas en cada uno de ellos, sin incluir las relaciones entre éstas.

3	Realización de Casos de Uso
Las realizaciones, están expresadas en términos de estructura e interacciones entre instancias que respeten dicha estructura. Concretamente, la parte estructural de una realización es un diagrama de clases conteniendo clases del modelo; la parte dinámica es un conjunto de diagramas de interacción que ilustran el flujo de mensajes entre instancias de las clases de la parte estructural correspondiente. 

Esta sección está dividida por colaboración. Una colaboración es la realización de uno o más casos de uso. Para cada colaboración habrá una sección que muestre su diseño. El nombre de una colaboración corresponde al nombre del caso de uso que realiza, o el nombre del “área temática” determinada por el conjunto de casos de uso que realiza. La estructura para presentar la información será la siguiente:
3.1	Colaboración 1
En esta sección se presenta la colaboración que realiza uno o más casos de uso. Simplemente se realiza un diagrama como el de la figura 2-1, en el cual se indica el nombre de la colaboración y los casos de uso que realiza.

Figura 2‑1:  Colaboración
3.1.1	Estructura
En esta sección se presenta el diagrama de clases correspondiente al diseño de ésta colaboración.

Es común que el tamaño de este diagrama complique su presentación en una sola carilla. En este caso, es permisible separar el diagrama en varias hojas con distintos niveles de detalle. Por ejemplo se puede mostrar un diagrama que tenga sólo las clases y dependencias entre las mismas, y luego varios diagramas para mostrar cada clase en detalle pero sin sus relaciones con otras clases.

Figura 2‑2:  Diagrama de Clases de Diseño
3.1.2	Interacciones
En esta sección se presentan los diagramas de comunicación para representar los aspectos dinámicos de la colaboración. Por cada operación se agrega la siguiente información.
3.1.2.1	Diagramas de comunicación de la operación 1
En esta sección se presenta el diagrama de comunicación de la operación indicada y un detalle de la asignación de responsabilidades correspondientes al diagrama.

A modo de ejemplo se incluye lo siguiente:

Figura 2‑3:  Diagrama de comunicación para la operación Obtener el tamaño del sistema de archivos

Asignación de responsabilidades:
•	Controller de la operación:  FileSystem.
•	Creador de Items:  FileSystem.
•	Destructor de Items:  Item.  FileSystem será responsable del Item raíz en el árbol del sistema de archivos.
3.1.3	Design Patterns
En esta sección se indican todos los Design Patterns involucrados en el diseño de la colaboración de esta sección. En caso de que la aplicación de este Design Pattern ya haya sido documentada (esto implica que las clases involucradas en el patrón sean las mismas) en alguna sección anterior sólo debe hacerse referencia a la misma. En caso que no se haya aplicado ningún Design Pattern esta sección no debe incluirse.
3.1.3.1	Design Pattern 1
Debe haber una sección como está por cada Design Pattern aplicado. Se debe indicar qué clases están involucradas, qué roles cumplen las mismas, y a su vez se debe dar una explicación textual que justifique su utilización.

A modo de ejemplo se incluye la siguiente especificación de un Design Pattern:
Dadas estas características se diseñó el sistema de archivos aplicando el Design Pattern Composite. 

Las clases involucradas son: 
-  Item, que cumple el rol de Component.
-  Archivo, que cumple el rol de Leaf.
-  Directorio, que cumple el rol de Composite.
4	Criterios Generales
En el diseño de un sistema típicamente existen ciertas decisiones que no se toman de manera local al realizar el diseño de un caso de uso sino que responden a una consideración global de las distintas funcionalidades que el sistema debe ofrecer.

A su vez suelen existir ciertos problemas que aparecen repetidamente en el sistema, y que por mantener una coherencia interna y facilitar la comprensión del diseño se resuelven siempre de la misma forma.

Esta sección está dedicada a explicar estos dos tipos de cuestiones que son globales y no dependen de cada caso de uso particular sino de una concepción general del diseño del sistema. Obviamente en caso de no existir ninguna decisión de este tipo, esta sección puede ser descartada.

A continuación se muestra un ejemplo:

En primer lugar, para asignar la responsabilidad de atender las operaciones del sistema se decidió definir un controlador para las operaciones relacionadas con dar de alta, baja y requerir información sobre los clientes; otro para este tipo de operaciones sobre los descuentos; y otro para este tipo de operaciones sobre las ventas.

También se definió un controlador que se encarga de las autorizaciones, ya sea para autenticar un local a la hora de inicializar el sistema, o para autorizar las tarjetas cuando se desea efectuar una compra o también para saber cuántos puntos genera una venta con un determinado monto. También se definió otro controlador para poder trabajar con el local que se encuentra logueado, es decir, en sesión. Todos estos controladores son Singleton.

En general se tomó el criterio de asignar la responsabilidad de destrucción de una instancia al mismo objeto que posee la responsabilidad de crearla.