Vous êtes sur la page 1sur 40

Curso de Diseo y Construccin de Productos de Software CLASE 2

Gloria Lucia Giraldo G. Escuela de Sistemas Semestre II de 2009

Contenido
Conversin del modelo conceptual al relacional Plan de capacidad Prediseo*

* Corresponde al Modelo de Anlisis de Jacobson, tambin llamado Modelo de Robustez

REPASO

Conversin E-A a Relacional


PELICULA # cdigo * titulo * ao * duracin
para originadora de

ACTUACION
de

ACTOR # cdula * nombre * apellido o nomArtstico

* rol
O

premio

contratado para

producida en

ESTUDIO #Identificador *nombre


lugar de realizacin de

Conversin E/A a Relacional


Convertir las entidades en relaciones
Nombre de la relacin 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

Conversin E/A a Relacional


Convertir los identificadores nicos en claves primarias:
Identificador nico con varios atributos => clave primaria compuesta

Conversin E/A a Relacional


Convertir las asociaciones en claves forneas: 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 relacin 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 relacin son obligatorios, la CF se debe colocar en cualquiera de los dos lados)

Conversin E/A a Relacional


Recomendado por

Claves Forneas (cont.):

Actor

Relaciones 1 a 1 opcionales en los dos sentidos: colocar la CF en cualquiera de las dos entidades. La CF admite nulos Relacin Recursiva 1 a muchos: se adiciona una columna CF a la tabla que referencia a la misma entidad. Una CF en una relacin 1 a 1 debe ser nica (clave alternativa) Relaciones muchos a muchos: Siempre se eliminan, descomponindolas dando origen a una tercera entidad

recomienda a

Conversin E/A a Relacional


Si el identificador nico est formado por relaciones con otras entidades, se deben generar las claves forneas respectivas y stas harn parte de la clave primaria

Conversin E/A a Relacional


Diseo de Arco explcito:
Una CF por cada asociacin incluida en el arco Se debe utilizar cuando las claves forneas tienen diferentes dominios (formatos). Para manejar la exclusividad se debe recurrir a una clusula de chequeo (check) la cual garantiza que si una CF es No nula las dems CFs del arco debern contener nulos

Arco Explicito

Conversin E/A a Relacional


Diseo de Arco genrico: - 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 fornea. 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 explcitamente ligada a ninguna de las entidades a las que referencia

Arco Genrico

Conversin E/A a Relacional


Supertipos/subtipos:

Conversin E/A a Relacional


Diseo de los subtipos en tablas diferentes.
El diseo se realiza as:
Crear una tabla para el supertipo: Crear una columna por cada atributo del supertipo Crear columnas CF para cada asociacin del supertipo.

Conversin E/A a Relacional


Crear una tabla para cada subtipo
Crear columnas para cada atributo propio del subtipo Crear columnas CF para cada asociacin del subtipo Crear una CF nica hacia el supertipo en todos los subtipos

PLAN DE CAPACIDAD

Plan de Capacidad
Refleja los niveles de utilizacin de recursos y el rendimiento de los servicios. Pronostica los requisitos de recursos futuros en funcin de la estrategia y planes de negocio

Plan de Capacidad
CONCURRENCIA
Nmero de usuarios concurrentes en Localizacin horas pico
unalmed 100

Nmero de usuarios concurrentes en horas normales


35

Total de usuarios
10000

Plan de Capacidad
REQUISITOS DE LAS TRANSACCIONES
Transaccin Bsqueda Actualizacin Insercin Eliminacin Tipo En linea En linea En linea En linea Frecuencia A solicitud A solicitud A solicitud A solicitud Prioridad (alta/media/baja) Alta Baja Alta Baja Complejidad (alta/promedi o/simple) Alta Simple Alta Simple Duracin Mxima 2 minutos 1 minuto 2 minutos 1 minuto Actividad en la base de datos Consulta Consulta, Actualizacin Consulta, insercin Consulta, eliminacin

Ejemplos: Bsqueda: Consulta alfabtica de pacientes Actualizacin: actualizar los datos generales del paciente Insercin: ingresar actividades realizadas por el mdico

Plan de Capacidad
DIMENSIONAMIENTO DE LOS OBJETOS DE DATOS

Prediseo o Modelo de Anlisis

Objetivo
El objetivo del modelo de anlisis es crear una arquitectura de objetos que sirva como base para el diseo del sistema. Dependiendo del tipo de aplicacin existen varias arquitecturas. Ellas se distinguen segn la organizacin de los objetos de acuerdo a su funcionalidad. Esto es llamado dimensin de la arquitectura.

Dimensin de la arquitectura
Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interaccin 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 informacin Modelo-Vista-Control (MVC) PREGUNTA: De cuntas dimensiones ser la mejor arquitectura? No depende tanto del nmero sino de la independencia entre las dimensiones.

Arquitectura Modelo-Vista-Control
Modelo informacin Vista presentacin o interaccin con el usuario Control comportamiento

M-V-C
El modelo tpicamente representa el dominio del problema, i.e. la informacin la cual se almacena en una BD. La vista corresponde a las interfaces que se le presentan al usuario para el manejo de la informacin. El control corresponde a la manipulacin de la informacin a travs de sus diversas presentaciones. De las tres, esta es la capa ms propensa a ser modificada

Diagrama de la Arquitectura del Modelo de Anlisis


estereotipo Control (Comportamiento)

estereotipo

estereotipo

Entidad (Informacin)

Borde (Interfaz) Estereotipo es el tipo de funcionalidad de un objeto dentro de una arquitectura Es difcil lograr una ortogonalidad completa de estereotipos, es comn que se traslapen.

Clases con estereotipos


Estereotipo Entidad: para los objetos que guardan informacin 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. Tambin una interfaz de usuario. Estereotipo Control: para objetos que implementan la lgica de los casos de uso. Ej: validar un usuario existente o insertar uno nuevo.

Representacin de los estereotipos


Dos formas:
<<Entidad>> Nombre de Clase1 <<Borde>> Nombre de Clase2 <<Control>> Nombre de Clase3

(a)

Nombre de Clase1

Nombre de Clase2 (b)

Nombre de Clase3

(b) Propuesto por Jacobson

Identificacin de clases segn 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 nmero de objetos posible.

Principios para la asignacin de objetos a cada caso de uso


Funcionalidades del caso de uso que dependen directamente de la interaccin del sistema con el mundo externo, se asigna a los objetos borde. Funcionalidades relacionadas con almacenamiento y manejo de informacin del dominio se asigna a los objetos entidad. Funcionalidades que afectan mltiples objetos a la vez o que no se relacionan naturalmente con ningn objeto borde o entidad, se asigna a los objetos control.

Identificacin 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

Identificacin 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 informacin 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 aplicacin. Cmo saber si cierta informacin se debe modelar como una entidad o como un atributo?

Identificacin de los objetos control


Se identifican principalmente a partir de los casos de uso. En la mayora 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 segn cada caso de uso


Despus 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 entregable

er 1

Diagrama de secuencias
Una vez identificadas las clases se hace necesario describir la interaccin entre ellas para lograr la funcionalidad. Para ello se utiliza el diagrama de secuencias. Este diagrama describe aspectos dinmicos 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 descripcin completa de ellos. Las clases de subrayan Los eventos de colocan en cursiva

Bibliografa
Capitulo 7 del libro Ingeniera de software orientada a objetos con UML, Java e Internet.