Programacin de Aplicaciones

Edicin 2009

Informe del
Modelo de Diseo

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 INTRODUCCIN 4
1.1 Propsito 4
1.2 Alcance4
1.3 Estructura del Documento 4
2 ORGANIZACIN LGICA 4
3 REALIZACIN DE CASOS DE USO 5
3.1 Colaboracin 1 5
3.1.1 Estructura 5
3.1.2 Interacciones 6
3.1.2.1 Diagramas de colaboracin de la operacin 1 6
3.1.3 Design Patterns7
3.1.3.1 Design Pattern 1 7
4 CRITERIOS GENERALES 7
1 Introduccin
1.1 Propsito
El propsito de este documento es brindar una descripcin general del Modelo de Diseo.

1.2 Alcance
El informe del Modelo de Diseo presenta una abstraccin de la solucin lgica 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 seccin presenta la organizacin lgica
del sistema en paquetes de diseo. La tercera seccin presenta las colaboraciones con la
realizacin de los casos de uso incluidos en el Modelo de Casos de Uso. Por ltimo, la cuarta
seccin presenta los criterios generales adoptados para el diseo 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 prrafo,
por una lnea a lo largo de su borde izquierdo. Estas secciones deben ser eliminadas de la
versin final del documento.

2 Organizacin Lgica
A los efectos de organizar la capa lgica se definen paquetes de diseo. Cada paquete de diseo
puede contener clases de diseo y otros paquetes de diseo. En esta seccin se incluyen los
paquetes de diseo existentes y las clases incluidas en cada uno de ellos, sin incluir las relaciones
entre stas.

Package
.

Package 1 Package 2

Package 1 Package 2
. .

Class2 Class3
Class1 Class6

Class4 Class5
.

.
3 Realizacin de Casos de Uso
Las realizaciones, estn expresadas en trminos de estructura e interacciones entre instancias que
respeten dicha estructura. Concretamente, la parte estructural de una realizacin es un diagrama
de clases conteniendo clases del modelo; la parte dinmica es un conjunto de diagramas de
interaccin que ilustran el flujo de mensajes entre instancias de las clases de la parte estructural
correspondiente.

Esta seccin est dividida por colaboracin. Una colaboracin es la realizacin de uno o ms
casos de uso. Para cada colaboracin habr una seccin que muestre su diseo. El nombre de
una colaboracin corresponde al nombre del caso de uso que realiza, o el nombre del rea
temtica determinada por el conjunto de casos de uso que realiza. La estructura para presentar
la informacin ser la siguiente:

3.1 Colaboracin 1
En esta seccin se presenta la colaboracin que realiza uno o ms casos de uso. Simplemente se
realiza un diagrama como el de la figura 2-1, en el cual se indica el nombre de la colaboracin y
los casos de uso que realiza.

Caso de Uso 1 Caso de Uso 2

Colaboracin 1

Figura 2-1: Colaboracin

3.1.1 Estructura
En esta seccin se presenta el diagrama de clases correspondiente al diseo de sta colaboracin.

Es comn que el tamao de este diagrama complique su presentacin 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 slo las clases y dependencias entre las
mismas, y luego varios diagramas para mostrar cada clase en detalle pero sin sus relaciones con
otras clases.
 Class1
Class2
-attribute1 : String
-attribute1 : int
-attribute2 : String
-attribute2 : String
-attribute3 : String
1 * -attribute3 : String
+operation1(in value : int)
+operation1(in parameter1 : String) : int
+operation2()

Class6 Class3 Class5 Class4

-attribute1 : int -attribute4 : String -attribute4 : String -attribute4 : String
+operation1() : boolean

0..1 *

Figura 2-2: Diagrama de Clases de Diseo

3.1.2 Interacciones
En esta seccin se presentan los diagramas de comunicacin para representar los aspectos
dinmicos de la colaboracin. Por cada operacin se agrega la siguiente informacin.

3.1.2.1 Diagramas de comunicacin de la operacin 1

En esta seccin se presenta el diagrama de comunicacin de la operacin indicada y un detalle
de la asignacin de responsabilidades correspondientes al diagrama.

A modo de ejemplo se incluye lo siguiente:

darTamao() 1: darTamao()
:FileSystem raiz:Directorio

No es necesario completar
el diagrama dado que se ajusta
a la interaccin del Design
Pattern Composite

Figura 2-3: Diagrama de comunicacin para la operacin Obtener el tamao del sistema de
archivos

Asignacin de responsabilidades:
0 Controller de la operacin: FileSystem.
1 Creador de Items: FileSystem.
2 Destructor de Items: Item. FileSystem ser responsable del Item raz en el rbol del sistema
de archivos.

3.1.3 Design Patterns

En esta seccin se indican todos los Design Patterns involucrados en el diseo de la colaboracin
de esta seccin. En caso de que la aplicacin de este Design Pattern ya haya sido documentada
(esto implica que las clases involucradas en el patrn sean las mismas) en alguna seccin
anterior slo debe hacerse referencia a la misma. En caso que no se haya aplicado ningn Design
Pattern esta seccin no debe incluirse.

3.1.3.1 Design Pattern 1

Debe haber una seccin como est por cada Design Pattern aplicado. Se debe indicar qu clases
estn involucradas, qu roles cumplen las mismas, y a su vez se debe dar una explicacin textual
que justifique su utilizacin.

A modo de ejemplo se incluye la siguiente especificacin de un Design Pattern:

Dadas estas caractersticas 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 diseo de un sistema tpicamente existen ciertas decisiones que no se toman de manera
local al realizar el diseo de un caso de uso sino que responden a una consideracin 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 comprensin del diseo se resuelven siempre de la
misma forma.

Esta seccin est dedicada a explicar estos dos tipos de cuestiones que son globales y no
dependen de cada caso de uso particular sino de una concepcin general del diseo del sistema.
Obviamente en caso de no existir ninguna decisin de este tipo, esta seccin puede ser
descartada.

A continuacin 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
informacin sobre los clientes; otro para este tipo de operaciones sobre los descuentos; y otro
para este tipo de operaciones sobre las ventas.

Tambin 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 tambin para saber cuntos puntos genera una venta con un determinado monto.
Tambin se defini otro controlador para poder trabajar con el local que se encuentra logueado,
es decir, en sesin. Todos estos controladores son Singleton.

En general se tom el criterio de asignar la responsabilidad de destruccin de una instancia al

mismo objeto que posee la responsabilidad de crearla.