Curso de Diseño y Construcción de Productos de Software CLASE 2 Gloria Lucia Giraldo G. Escuela de Sistemas Semestre II de 2009

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 PELICULA # código * titulo * año * duración ACTUACION * rol O premio ACTOR # cédula * nombre * apellido o nomArtístico para de originadora de contratado para producida en ESTUDIO #Identificador *nombre lugar de realización 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 Actor recomienda a Recomendado por 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 La cf en una relación 1 a 1 es una clave alternativa porque si sólo puede aparecer una vez, quiere decir que es ubn

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 CONCURRENCIA

Plan de Capacidad REQUISITOS DE LAS TRANSACCIONES Ejemplos: Ejemplo de prioridad media: “ingresar una sugerencia” 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 estereotipo Control (Comportamiento) estereotipo Entidad (Información) estereotipo Borde (Interfaz) Estereotipo es el tipo de funcionalidad de un objeto dentro de una arquitectura Es 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 Dos formas: <<Entidad>> Nombre de Clase1 <<Borde>> Nombre de Clase2 <<Control>> Nombre de Clase3 (a) Nombre de Clase1 Nombre de Clase2 Nombre de Clase3 (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.