Diseño

Al finalizar el capítulo, el alumno podrá:

 Transformar el modelo de análisis en un modelo de datos de diseño.

 Generar código para la creación de una Base de Datos
 Identificar los elementos de un diagrama de interacción de diseño y elaborar los
diagramas de secuencia y comunicación.
 Generar código para la creación de componentes de programación.

Temas

1. Disciplina RUP de Análisis y Diseño.

2. Modelos de Diseño.

Programa UML 2.4.1 for Developer- Enterprise Architect

Diseño 186

1. Disciplina de Análisis y Diseño

Principales objetivos de la etapa de Diseño.

 Modelar el sistema y encontrar su forma exacta para que soporte el sistema.

 Adquirir una comprensión profunda de los aspectos relacionados con los requisitos
no funcionales y restricciones relacionadas con los lenguajes de programación,
componentes reutilizables, sistemas operativos, entre otros.
 Crear una entrada apropiada para las actividades de implementación.
Diseño 187

Modelo de Análisis Modelo de Diseño

Modelo Conceptual, porque es una Modelo Físico, porque es un plano de la
abstracción del sistema y permite aspectos de implementación.
la implementación.
Genérico respecto al diseño (aplicable a varios No genérico, especifico para una
diseños). implementación.
Tres estereotipos conceptuales sobre las Cualquier número de estereotipos (físicos)
clases: Boundary, Control y Entity. sobre las clases, depende del lenguaje de
implementación.
Menos Formal. Más Formal.
Menos Capas. Más Capas.

Dinámico, no muy centrado en la secuencia. Dinámico, muy centrado en la secuencia.

Puede no ser mantenido durante el ciclo de Debe ser mantenido durante todo el ciclo de
vida del software. vida del software.
Define una estructura que es una entrada Da forma al sistema, mientras que intenta
esencial para modelar el sistema. preservar la estructura definida por el modelo
de análisis lo más posible.

Tabla 1. Comparación entre el Modelo de Análisis y el Modelo de Diseño.

Características de un modelo de diseño:

 Satisface los requisitos del sistema.

 Es resistente a cambios en el entorno de implementación.
 Es fácil de mantener en relación con otros posibles modelos de objeto y para la
implementación del sistema.
 Existe claridad para ser implementado.
 No incluye información que esté mejor documentada en el código del programa.
 Es fácil de adaptar a cambios en requisitos.
Diseño 188

1.1. Disciplina RUP: Análisis y Diseño

Las actividades de diseño se desarrollan durante la última parte de la fase de

elaboración y la primera mitad de la fase de construcción. En cierta forma, el
Análisis y el Diseño pueden ocurrir en paralelo.

Asimismo, puede definirse al modelo de diseño como una elaboración del

modelo de análisis con detalle añadido y soluciones técnicas especificas. Del
mismo modo, el modelo de diseño contiene los mismos elementos del modelo
de análisis pero los artefactos están mejor formados y deben incluir detalles de
implementación.
Diseño 189

2. Desarrollo de las Actividades de la Disciplina de Análisis y

Diseño

2.1. Elementos
Los modelos de diseño contienen elementos definidos que facilitan su
representación.

Los elementos principales en Diseño son:

 Clases y Objetos.
 Interfaces.
 Asociaciones.

Proveedor
-CodProveedor : String
-RazSocProve : String
-RUCProve : String
-DirecProve : String
«interface»
-TlfProve : String
IReporteControl
-ContactoProve : String
+creaReporte()
-CelConProve : String
+configuraReporte()
+GrabarProveedor()
+ConsultarProveedor()
+BajaProveedor()
+GeneraCodigoProvee() IReporteControl

Clases de Diseño Interfaz

Diseño 190

2.1.1. Clases de diseño

Una clase es una descripción de un grupo de objetos con propiedades

en común (atributos), comportamiento similar (operaciones), la misma
manera de relacionarse entre objetos (asociaciones y agregados) y una
semántica en común. Un objeto es la instancia de una clase.

Además, una clase es una abstracción donde:

- Se enfatizan las características relevantes.
- Se suprimen otras características.

 Nombramiento de clases

El nombre de la clase debe ser el sustantivo singular que mejor

caracterice la abstracción. Sin embargo, la dificultad al nombrar la clase
revela una pobre definición de la abstracción.
Los nombres deben provenir directamente del vocabulario del dominio.

Una guía de estilo debe dictar convenciones para el nombramiento de

clases. Por ejemplo:

- Las clases son nombradas usando sustantivos singulares.

- Los nombres de las clases comienzan con letra mayúscula.
- No se usa el subrayado.
- Los nombres compuestos por múltiples palabras se ponen juntos y
la primera letra de cada palabra se escribe con mayúscula
(ejemplo: estudiante, profesor, sistemadepago).

 Definiendo la semántica de las clases

Después de nombrar las clases, debe hacerse un informe descriptivo

conciso y concentrarse en el propósito de la clase, no en su
implementación.
El nombre y la descripción de la clase sirven como base para un
modelo de diccionario.

Fijarse en los “QUÉ” e ignorar los “CÓMO”

 Notación de clases en UML

Una clase es representada usando un compartimiento rectangular, la

cual contiene tres secciones:

- La primera sección contiene el nombre de la clase.

- La segunda sección muestra la estructura (atributos).
- La tercera sección muestra el comportamiento (operaciones).

La segunda y la tercera sección pueden ser suprimidas, si se necesita

que no se vean en el diagrama.

Notación UML
Diseño 191

Una clase puede tener atributos (datos) y métodos (operaciones o

comportamiento). Además, puede heredar características desde las
clases padres y delegar comportamientos a otras clases. Los modelos
de Clases usualmente describen la estructura lógica del sistema y son
los bloques de construcción, a partir de los cuales se construyen los
componentes.

Una clase de diseño representa una abstracción de una o varias

clases en la implementación del sistema; exactamente, a qué
corresponde depende del lenguaje de implementación. Por ejemplo, en
un lenguaje orientado a objetos como C++, una clase puede
corresponder a una clase plana, o en Ada, una clase puede
corresponder a un tipo etiquetado definido en la parte visible del
paquete.

Las clases definen objetos, que a su vez, implementan los casos de

uso. Además, una clase se origina, a partir de los requisitos que las
ejecuciones de casos de uso hacen en los objetos necesarios en el
sistema, así como, cualquier modelo de objeto desarrollado
anteriormente.

 Estereotipos

Para asignar un estereotipo se considera que el lenguaje utilizado para

especificar la clase es lo mismo que el lenguaje de programación. En
consecuencia, las operaciones, atributos, parámetros, tipos y demás,
serán especificados, según el lenguaje de programación elegido.

Ejemplos en Visual Basic:

- «ClassModule»
- «Form»
- «UserControl»

 Correlación con el Modelo de Análisis

Para modelar esta rastreabilidad, una dependencia de rastreo debe

dibujarse desde el elemento de diseño hasta las clases de análisis que
representan, tal como se muestra en el diagrama siguiente.

Nota:

Los enlaces de rastreabilidad se dibujan desde los elementos del modelo de

diseño hacia los elementos del modelo de análisis, para que el modelo de
diseño sea dependiente del modelo de análisis y no al contrario.
Diseño 192

2.1.2. Objetos

Un objeto es una instancia de una clase en tiempo de ejecución. Se

representa de la misma forma que una clase.

En el compartimiento superior aparece el nombre del objeto junto con

el nombre de la clase subrayado.

Sintaxis:

- Objeto : Clase

Julio : Alumno

Alumno Codigo = A022

Apellidos = Paz
-Codigo Nombres = Julio
-Apellidos
-Nombres Julio : Alumno

Julio

2.1.3. Interfaces

Una interface es una colección de operaciones que son usadas para

especificar un servicio de una clase o componente. A diferencia de las
clases, las interfaces no especifican ninguna estructura, no incluyen
atributos, ni implementación o métodos.
Diseño 193

Éstas se utilizan para visualizar, especificar, construir y documentar las

líneas de separación dentro de un sistema.

2.1.4. Asociaciones

 Navegabilidad: muestra que es posible pasar desde un objeto de la

clase fuente a uno o más objetos de la clase destino, dependiendo
de la multiplicidad.

Para el ejemplo: un objeto pedido almacena los datos del cliente; pero,
un objeto cliente no almacena una lista de pedidos.

Para este paso se recomienda:

- Evaluar la asociación y determinar cuál es la clase dependiente

para colocar la navegación. Además, se debe identificar qué
clase conocerá el contenido de la otra.

 Agregación y Composición: en diseño, se puede convertir una

relación de asociación en una relación de agregación o una forma
mayor de agregación conocida como la relación de agregación de
composición, si la semántica de la asociación lo garantiza.

 Agregación
Es un tipo de relación todo-parte en la que el conjunto se compone
de muchas partes. El objeto (todo) utiliza los servicios de otro objeto
(parte).

Computadora Impresora

0..1 0..*

Todo o parte
conjunto

 Composición
Es una forma más fuerte de agregación. Al igual que la agregación,
es una relación todo-parte y es tanto transitiva como asimétrica. En
la composición, las partes no tienen vida independiente fuera del
todo.

Compuesto parte
Diseño 194

2.2. Diagrama de Clases de Diseño

La actividad de construcción del modelo de diseño consta de varias sub
actividades.

Para la construcción del diagrama de clases de diseño, se realiza lo siguiente.

- Realización de los casos de uso de diseño, a partir de las realizaciones de

análisis.
- Identificación de las clases de diseño.
- Construir el diagrama de clases de diseño.

2.2.1. Realizaciones de Casos de Uso

«Realize»
Realizacion de Caso Realizacion Caso
de Uso Analisis de Uso - diseño

Es una colaboración de objetos de diseño y clases que realizan un

caso de uso. Existe un realize entre la realización de un caso de uso
de análisis y uno de diseño.

La realización de diseño especifica decisiones de implementación y

realiza los requisitos no funcionales.

La realización de los casos de uso de diseño se apoya en:

- Diagramas de interacción de diseño.

- Diagramas de clase que contienen las clases de diseño que
participan.

Nota:
El nombre de la realización del caso de uso de diseño debe ser igual al de su
respectiva realización de caso de uso de análisis.

2.2.2. Identificación de Clases de Diseño

El proceso de identificación es similar al proceso de análisis, pero con

la diferencia de que los estereotipos son de diseño.
Según se revisó puntos atrás, para asignar un estereotipo se considera
que el lenguaje utilizado para especificar la clase es lo mismo que el
lenguaje de programación. En consecuencia, las operaciones,
atributos, parámetros, tipos y demás, serán especificados según el
lenguaje de programación elegido.
Diseño 195

Asimismo, por cada par, actor - escenario de caso de uso, se deberán

encontrar las clases necesarias para implementar el caso de uso,
basado en el análisis efectuado.

2.2.3. Construir el diagrama de clases de diseño

El diagrama de clases de diseño es una herramienta de UML que

muestra la estructura estática del sistema. Además, modela la
colaboración entre las clases de diseño que conforman del sistema.

Un diagrama de clases de diseño describe la realización de un caso de

uso del sistema.
Diseño 196

Laboratorio Nº 17

Identificar los elementos de diseño para la construcción de los modelos lógico,

físico y la generación de la base de datos.

Objetivo:

 Realizar el modelado de diseño en su versión inicial: diagrama de clases de diseño.

Duración:

20 minutos

Descripción:

Se formarán equipos de dos personas y según el enunciado:

 Identificará las clases de diseño, según el lenguaje de programación seleccionado.
 Luego, creará las clases de Diseño en los paquetes correspondientes.
 Finalmente, elaborará el Diagrama de Clases de Diseño.

Enunciado:

Solicite el enunciado a su instructor.

Notas:
Diseño 197

2.3. Diagramas de Iteración

Los diagramas de iteración son una representación gráfica de iteraciones entre

objetos. Permiten la identificación de las operaciones de las clases que
conformarán los componentes a implementar.

UML presenta 3 diagramas de iteración:

 Diagrama de Secuencia.
 Diagrama de Comunicación.
 Diagrama de Visión de Interacción.

(Para revisar la estructura y elementos es oportuno revisar el Anexo B)

Diseño 198

Laboratorio Nº 18

Identificar los elementos de un diagrama de interacción

de diseño y elaborar los diagramas de secuencia y comunicación

Objetivo:

 Realizar los diagramas de interacción de diseño: diagrama de secuencia y diagrama de

comunicación.

Duración:

30 minutos

Descripción:

Se formarán equipos de dos personas y según el enunciado:

 Identificará los elementos de los Diagramas de Interacción.

 Luego, creará los objetos y elementos necesarios.
 Finalmente, elaborará el Diagrama de interacción.

Enunciado:

Solicite el enunciado a su instructor

Notas:
Diseño 199

2.4. Modelo Lógico

El Modelo Lógico termina de refinar el Modelo Conceptual, es aquí donde se
reducen y/o aumentan las clases, quedando aquellas que van a ser diseñadas
como tablas de la base de datos (clases relevantes) que almacenarán la
información del sistema.

Cabe mencionar que es necesario identificar las asociaciones entre las clases
que se requieren, para satisfacer los requerimientos de información y que
contribuyan a entender el dominio del problema. Sin olvidar que es más
importante identificar las clases que las asociaciones.

Además, el modelo lógico obliga a mostrar detalles de las clases para mejorar la
explicación de las reglas del negocio. En este modelado, la normalización es
implícita y la base de datos queda estructurada para cambios futuros por el
cliente, patrocinador o usuario.

Por su parte, el diagrama de clases permite el análisis y diseño, y representa al

modelo lógico. A su vez, presenta las clases y objetos del sistema con sus
relaciones estructurales y de herencia.

El trabajo realizado en los diagramas de casos de uso, diagramas de secuencia y

diagramas de colaboración, aporta información para establecer las clases,
objetos, atributos y métodos.

 Restricciones

Una restricción es una expresión de alguna condición que se debe preservar.

Se denota con llaves.

Algunas consideraciones para elaborar un Modelo Lógico son las siguientes.

- Colocar las multiplicidades y navegabilidad entre las clases.
- Identificar los atributos de enlace o clase de enlace de las asociaciones
muchos a muchos (1..* - 0..*). Además, esto tiende a reducir a cero los
datos nulos o vacíos.
- Identificar las clases que tendrán sus propios atributos (inherentes);
luego, asociarlos por navegación (asociación unidireccional); esto evita
redundancia de atributos.
- No incluir los atributos identificadores de las clases, por ser implícitos (se
agregan en el diseño del modelo físico).
Diseño 200

- Incluir todos los atributos a las clases que se necesitan para satisfacer
los requerimientos. En la superclase van los atributos comunes en las
subclases y en éstas, atributos que los identifican de sus otras
subclases.
- Documentar un registro de glosario de términos usados en el ADOO.
- Verificación que las reglas del negocio se sigan cumpliendo con el
modelo lógico.

Patrones de Ayuda en la elaboración del Modelo Lógico.

 Patrón: Asociación clave Foránea

En modelo de clases, no se utiliza la clase asociación. Para modelar este
escenario, se debe convertir usando composición y agregación.

Ejemplo:

- En el modelo conceptual Refinado

-
class Entity2
En el Modelo Lógico

OrdenCompra Insumo

- Num_OrdCom: Integer - Cod_insumo: Integer

- Fec_OrdCom: Datetime - Des_insumo: String
- Glo_OrdCom: String - Stk_insumo: Double
1 +producto 1

Insumo_OrdCom
+items
- Can_items: Integer
1..*
0..*
Diseño 201

2.4.1. Generación de código

Las clases brindan información para todo nivel, incluyendo el nombre

de las operaciones que van a conformar las clases a nivel
programación.

Para observar este código antes de ser generado, se debe seleccionar

una clase y observar las operaciones, según la herramienta que se
esté utilizando.

Distrito 1
-CodDistrito : String
-DesDistrito : String
+CargaDistrito() -wdistrito 0..*

Proveedor
-CodProveedor : String
-RazSocProve : String
-RUCProve : String
-DirecProve : String
-TlfProve : String
-ContactoProve : String
-CelConProve : String
+GrabarProveedor()
+ConsultarProveedor()
+BajaProveedor()
+GeneraCodigoProvee()

Cabe resaltar que la generación de código solo está referida a la

creación de los Namespace hasta la declaración completa de la clase;
el resto, tendrá que ser completado por el programador.

 Ejemplo de la clase Proveedor:

Imports LogicalView.DesignModel.ElementosdeDiseño
Namespace LogicalView.DesignModel.ElementosdeDiseño

Public Class Proveedor

Private CodProveedor As String
Private RazSocProve As String
Private RUCProve As String
Private DirecProve As String
Private TlfProve As String
Private ContactoProve As String
Private CelConProve As String
Private wTipProv As
LogicalView.DesignModel.ElementosdeDiseño.TipoProveedor
Private wdistrito As
LogicalView.DesignModel.ElementosdeDiseño.Distrito

Public Sub GrabarProveedor ()

End Sub

Public Sub ConsultarProveedor ()

End Sub

End Class ' END CLASS DEFINITION Proveedor

End Namespace ' LogicalView.DesignModel.ElementosdeDiseño
Diseño 202

Laboratorio No. 19:

Generar scripts para la construcción de clases

Objetivos:

 Elaborar el Modelo Lógico con las clases de diseño y genera el código de las mismas.

Duración:
30 minutos

Descripción:
Se formarán equipos de dos personas y según el enunciado:
 Identificará las clases de diseño de acceso a datos y las estructuras.
 Luego, elaborará el Modelo Lógico.
 Finalmente, generará código con las clases de diseño en todos los niveles:
Presentación, Lógica de Negocio y Datos.

Enunciado:
Solicite el enunciado a su instructor

Notas:
Diseño 203

2.5. Modelo Físico

El modelo de datos es la representación de la vista física de los datos, por lo

tanto, es dependiente del tipo de base de datos escogido.

Un modelo de datos está compuesto por:

- Tablas.
- Columnas o campos.
- Llaves primarias y foráneas.
- Restricciones.
- Índices.
- Relaciones.
- Diagrama del Modelo de Datos.

Además, el modelo físico es el modelo de la base de datos. Permite generar los

Scripts para crear la base de datos.

 Clases Persistentes (Tablas)

Para la creación del modelo físico, se toman los atributos de las clases
creadas en el modelo lógico de datos, así como, los atributos que identifican
a la clase y se llamarán Llave primaria o Primary Key y los campos por los
cuales, se conectan las clases serán las llaves foráneas o Foreing Key.

En cuanto a la nomenclatura a usar, existen diferentes versiones. Cada

empresa tiene su propio estándar de definición de nombres para el diseño
de sus elementos: nombre para las tablas, nombre para los campos
(atributos), nombre para la llave primaria, nombre para las llaves foráneas,
entre otros.
Diseño 204

a. Tablas: se podrá usar el nombre de la tabla y se le adiciona el prefijo T.

Por ejemplo: Tnombredelatabla.

Ejemplo:

CLASE TABLA
Profesor TProfesor
Alumno TAlumno
OrdenCompra TOrdenCompra

b. Campos: pueden incluir una, dos y/o hasta tres sílabas.

Ejemplo:
TIPO DE CAMPO EJEMPLO
CodProfe
- Códigos CodAlumno
CodProveedor
NomProfesor
- Nombres
NomAlumno
DesProducto
- Descripciones
DesAmbiente
FecNacim
- Fechas FecIngreso
FecVcto

c. Llaves Primarias: para crear la llave ID_nombredelatabla (los campos

que forman la llave primaria).

Ejemplo:
TABLA LLAVE PRIMARIA
TProfesor Id_profesor
TAlumno Id_alumno
TOrdenCompra Id_ordencompra

d. Llaves Foráneas: para crear llaves foráneas FK_Nombredelatabla

(campo(s) que forman parte de la llave primaria de la tabla Padre)

Ejemplo:
HACIA LA TABLA LLAVE FORÁNEA
TProfesor fk_profesor
TAlumno fk_alumno
TOrdenCompra fk_ordencompra
Diseño 205

e. Índices: para crear índices: INDEX_Nombredelcampo (campo de

referencia)

Ejemplo:

CAMPO ÍNDICE
NomProfe index_nomprofe
FecNacim index_fecnacim
index_desproducto
DesProducto

Ejemplos:

a. Definición de una tabla clase independiente.

Tespecialidad
PK CodEspe

I1 NomEspe

 Tabla:
TESPECIALIDAD
 Campos:
CODESPE, CHAR(3), NOT NULL
NOMESPE, CHAR(35), NOT NULL
 Llave Primaria:
ID_ESPECIALIDAD= CODESPE
 Índices:
INDEX_NOMESPE= NOMESPE

b. Definición de una tabla clase Dependiente.

Tprofesor
Tcondicion
PK CodProfe
PK CodCondicion
I1 NomProfe
DirProfe I1 DesCondicion
FK1 CodCondicion

PASO1: Tabla independiente

 Tabla independiente:
TCONDICION
 Campos:
CODCONDICION, CHAR(3), NOT NULL
DESCONDICION, CHAR(20), NOT NULL
 Llave Primaria:
ID_CONDICION(CODCONDICION)
 Índices:
INDEX_DESCONDICION(DESCONDICION)
Diseño 206

PASO2: Tabla dependiente

 Tabla dependiente:
TPROFESOR
 Campos:
CODPROFE, CHAR(3), NOT NULL, UNIQUE
NOMPROFE, CHAR(25), NOT NULL
DIRPROFE, CHAR(30), NOT NULL,
CODCONDICION, CHAR(3), NOT NULL
 Llave Primaria:
ID_PROFESOR(CODPROFE)
 Llave Foránea:
FK_CONDICION(CODCONDICION)
 Índices:
INDEX_NOMPROFE (NOMPROFE)
INDEX_CODCONDICION(CODCONDICION)

2.5.1. Construcción del Modelo de Almacenamiento

El Modelo de Almacenamiento es la representación de la vista física de

la arquitectura de almacenamiento de los datos. Contiene los
elementos de almacenamiento de base de datos y es dependiente de
esta base de datos.

Asimismo, el modelo de almacenamiento está compuesto por:

- Componentes de base de datos.

- Tablespaces.
- Script de la Base de Datos física.
- Diagrama de componentes. (Ver capitulo de despliegue)
Diseño 207

2.6. Diagrama de Máquina de Estado

solicitada
solicitar() [verificar=no]
entry/verificar prerequesitos rechazada
exit/UninterpretedAction1
consultar()[ solo si,,,,] [verificar=si]

cancelar() aprobada
cancelada

cancelar()[si no hay deuda]

activa

debitar()

bloqueada CancelaRobo(pin)

Un diagrama de máquina de estado modela el comportamiento de un único

objeto, especificando la secuencia de eventos que un objeto atraviesa durante
su tiempo de vida en respuesta a los eventos.

Ver anexo C.
Diseño 208

Laboratorio Nº 20

Identificar los elementos usados en los diagramas de máquina de estados

y elaborar un diagrama con la entidad más significativa

Objetivos:

 Identificar los elementos que intervienen en la elaboración de un modelo físico de

datos.
 Importar los elementos necesarios de la versión 2.X de UML, así como, asociar
correctamente, los elementos del diagrama y generar los scripts necesarios para la
creación de las tablas y relaciones en la base de datos escogida.

Duración:

30 minutos

Descripción:

Se formarán equipos de dos personas y según el enunciado:

 Identificará los elementos físicos y elabora el Modelo.

 Posteriormente, generará el script para la generación de la Base de Datos.
Diseño 209

Enunciado:
Solicite el enunciado a su instructor

Notas: