Gloria Lucia Giraldo G.Escuela de SistemasSemestre II de 2009
Curso de Diseño y Construcción de Productos de Software
CLASE 2
Contenido
• Conversión del modelo conceptual al relacional
• Plan de capacidad
• Prediseño*
* Corresponde al Modelo de Análisis de Jacobson, también llamado Modelo de Robustez
REPASO
Conversión E-A a Relacional
ACTOR
# cédula* nombre* apellidoo nomArtístico
ACTUACION
* rolO premio
ESTUDIO
#Identificador*nombre
PELICULA
# código* titulo* año* duración
producida en
lugar de realización de
contratadopara
depara
originadora de
Conversión E/A a Relacional
• Convertir las entidades en relaciones– Nombre de la relación igual al de la entidad en
el diagrama E/A (algunos recomiendan plural)• Convertir los atributos en columnas
– Atributos obligatorios son No Nulos– Nombres cortos pero significativos (pueden ser
los mismos que tienen en el modelo E/A), pueden ser abreviaturas consistentes
Conversión E/A a Relacional
• Convertir los identificadores únicos en claves primarias:– Identificador único con varios atributos =>
clave primaria compuesta
Conversión E/A a Relacional
• Convertir las asociaciones en claves foráneas:– Asignar un nombre de columna para la CF y rotularlo
“CF”.– Relaciones 1 a muchos: La CF se coloca en la
entidad a la que “le llega” cardinalidad muchos.– Si la relación es obligatoria (en el lado de la entidad
que posee la CF), la CF debe ser NN.– Relaciones 1 a 1: Colocar CF en el lado de la
obligatoriedad y debe ser NN.(Si ambos lados de la relación son obligatorios, la CF se debe colocar en cualquiera de los dos lados)
Conversión E/A a Relacional
• Claves Foráneas (cont.):– Relaciones 1 a 1 opcionales en los dos sentidos:
colocar la CF en cualquiera de las dos entidades. La CF admite nulos
– Relación Recursiva 1 a muchos: se adiciona una columna CF a la tabla que referencia a la misma entidad.
– Una CF en una relación 1 a 1 debe ser única (clave alternativa)
– Relaciones muchos a muchos: Siempre se eliminan, descomponiéndolas dando origen a una tercera entidad
Actorrecomienda a
Recomendado por
Conversión E/A a Relacional
– Si el identificador único está formado por relaciones con otras entidades, se deben generar las claves foráneas respectivas y éstas harán parte de la clave primaria
Conversión E/A a Relacional
Diseño de Arco explícito: – Una CF por cada asociación incluida en el arco
– Se debe utilizar cuando las claves foráneas tienen diferentes dominios (formatos).
– Para manejar la exclusividad se debe recurrir a una cláusula de chequeo (check) la cual garantiza que si una CF es No nula las demás CF’s del arco deberán contener nulos
Arco Explicito
Conversión E/A a Relacional
Diseño de Arco genérico:
- Una sola columna que funcionará como CF para todas las relaciones en el arco.
– Una columna adicional para saber cual de las tablas se referencia en la clave foránea.
– Si el arco es obligatorio, se debe exigir que la CF sea NO nula.
– El dominio debe ser igual en todas las CFs del arco
– La columna que funciona como CF para todas las relaciones no queda explícitamente ligada a ninguna de las entidades a las que referencia
Arco Genérico
Conversión E/A a Relacional
• Supertipos/subtipos:
Conversión E/A a Relacional
Diseño de los subtipos en tablas diferentes.
El diseño se realiza así:– Crear una tabla para el supertipo:– Crear una columna por cada atributo del
supertipo– Crear columnas CF para cada asociación del
supertipo.
Conversión E/A a Relacional
Crear una tabla para cada subtipo–Crear columnas para cada atributo
propio del subtipo–Crear columnas CF para cada
asociación del subtipo–Crear una CF única hacia el supertipo
en todos los subtipos
PLAN DE CAPACIDAD
Plan de Capacidad
• Refleja los niveles de utilización de recursos y el rendimiento de los servicios.
• Pronostica los requisitos de recursos futuros en función de la estrategia y planes de negocio
Plan de Capacidad
Localización
Número de usuarios concurrentes en horas pico
Número de usuarios concurrentes en horas normales Total de usuarios
unalmed 100 35 10000
CONCURRENCIA
Plan de Capacidad
REQUISITOS DE LAS TRANSACCIONES
Transacción Tipo FrecuenciaPrioridad
(alta/media/baja)
Complejidad (alta/promedi
o/simple)Duración Máxima
Actividad en la base de
datos
Búsqueda En linea A solicitud Alta Alta 2 minutos Consulta
Actualización En linea A solicitud Baja Simple 1 minutoConsulta, Actualización
Inserción En linea A solicitud Alta Alta 2 minutosConsulta, inserción
Eliminación En linea A solicitud Baja Simple 1 minutoConsulta, eliminación
Ejemplos:Búsqueda: “Consulta alfabética de pacientes”Actualización: “actualizar los datos generales del paciente”Inserción: “ingresar actividades realizadas por el médico”
Plan de Capacidad
DIMENSIONAMIENTO DE LOS OBJETOS DE DATOS
Prediseño o Modelo de Análisis
Objetivo
• El objetivo del modelo de análisis es crear una arquitectura de objetos que sirva como base para el diseño del sistema.
• Dependiendo del tipo de aplicación existen varias arquitecturas. Ellas se distinguen según la organización de los objetos de acuerdo a su funcionalidad. Esto es llamado dimensión de la arquitectura.
Dimensión de la arquitectura
• Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interacción externa.
• Dos dimensiones: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas
• Tres dimensiones: la mas utilizada en los sistemas de información Modelo-Vista-Control (MVC)
PREGUNTA: De cuántas dimensiones será la mejor arquitectura? No depende tanto del número sino de la independencia entre las dimensiones.
Arquitectura Modelo-Vista-Control
• Modelo información
• Vista presentación o interacción con el usuario
• Control comportamiento
M-V-C
• El modelo típicamente representa el dominio del problema, i.e. la información la cual se almacena en una BD.
• La vista corresponde a las interfaces que se le presentan al usuario para el manejo de la información.
• El control corresponde a la manipulación de la información a través de sus diversas presentaciones. De las tres, esta es la capa más propensa a ser modificada
Diagrama de la Arquitectura del Modelo de Análisis
Entidad(Información)
Control(Comportamiento)
Borde(Interfaz)
estereotipo
estereotipo
estereotipo
Estereotipo es el tipo de funcionalidad de un objeto dentro de una arquitecturaEs difícil lograr una ortogonalidad completa de estereotipos, es común que se traslapen.
Clases con estereotipos
• Estereotipo Entidad: para los objetos que guardan información sobre el estado interno del sistema; estos objetos corresponden al dominio del problema. Ej: un registro de usuario con sus datos.
• Estereotipo Borde: para objetos que implementan las interfaces del sistema con el mundo externo; corresponde a todos los actores incluyendo los no humanos. Ej: un objeto que se comunica con una BD externa al sistema. También una interfaz de usuario.
• Estereotipo Control: para objetos que implementan la lógica de los casos de uso. Ej: validar un usuario existente o insertar uno nuevo.
Representación de los estereotipos
<<Entidad>>Nombre de Clase1
<<Borde>>Nombre de Clase2
<<Control>>Nombre de Clase3
Nombre de Clase1 Nombre de Clase2 Nombre de Clase3
Dos formas:
(a)
(b)
(b) Propuesto por Jacobson
Identificación de clases según estereotipos en los casos de uso
• Se comienza identificando, para cada caso de uso, los objetos borde necesarios, luego los objetos entidad y por ultimo los objetos control.
• Se identifican los objetos comunes a varios casos de uso. Cuando un conjunto de objetos ya existe, estos se pueden modificar para adaptarse a un nuevo caso de uso. La meta es formar una arquitectura que reutilice el mayor número de objetos posible.
Principios para la asignación de objetos a cada caso de uso
• Funcionalidades del caso de uso que dependen directamente de la interacción del sistema con el mundo externo, se asigna a los objetos borde.
• Funcionalidades relacionadas con almacenamiento y manejo de información del dominio se asigna a los objetos entidad.
• Funcionalidades que afectan múltiples objetos a la vez o que no se relacionan naturalmente con ningún objeto borde o entidad, se asigna a los objetos control.
Identificación de los objetos borde
• Con base en los actores*• Con base en las descripciones de las interfaces
del sistema (modelo de requisitos)• Con base en las descripciones de los casos de
uso.
*Una interfaz por cada actor y la pantalla del prototipo que se colocó en el caso de uso
Identificación de los objetos entidad
• Se identifican principalmente a partir del dominio del problema del modelo de requisitos.
• Corresponden a objetos que sirven para modelar la información que el sistema debe manejar a corto o largo plazo.
• Los casos de uso sirven como base para determinar los objetos entidad que son necesarios para la aplicación.
• Cómo saber si cierta información se debe modelar como una entidad o como un atributo?
Identificación de los objetos control
• Se identifican principalmente a partir de los casos de uso.
• En la mayoría de los sistemas es suficiente con definir un solo objeto control para cada caso de uso.
• El comportamiento que no se asignó a los objetos borde y a los objetos entidad se asigna a los objetos control.
Clases estereotipadas según cada caso de uso
• Después de identificar las clases, cada caso de uso tiene asociado un conjunto de clases (borde, entidad y control)
Caso de uso X Caso de uso Y
Hasta aquí para el 1er entregable
Diagrama de secuencias
• Una vez identificadas las clases se hace necesario describir la interacción entre ellas para lograr la funcionalidad.
• Para ello se utiliza el diagrama de secuencias.
• Este diagrama describe aspectos dinámicos de un sistema. Por ello, el DS utiliza objetos en lugar de clases.
Insertando las secuencias en los Casos de uso
• Una vez elaborados los diagramas de secuencias, éstas se insertan en los casos de uso, para así generar una descripción completa de ellos.
• Las clases de subrayan
• Los eventos de colocan en cursiva
Bibliografía
• Capitulo 7 del libro “Ingeniería de software orientada a objetos con UML, Java e Internet.