Curso de Diseño y Construcción de Productos de Software CLASE 2

Presentación del tema: "Curso de Diseño y Construcción de Productos de Software CLASE 2"— Transcripción de la presentación:

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

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

3 REPASO

4 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

5 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

6 Conversión E/A a Relacional
Convertir los identificadores únicos en claves primarias: Identificador único con varios atributos => clave primaria compuesta

7 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)

8 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

9 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

10 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

11 Arco Explicito

12 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

13 Arco Genérico

14 Conversión E/A a Relacional
Supertipos/subtipos:

15 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.

16 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

17 PLAN DE CAPACIDAD

18 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

19 Plan de Capacidad CONCURRENCIA

20 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”

21 Plan de Capacidad DIMENSIONAMIENTO DE LOS OBJETOS DE DATOS

22 Prediseño o Modelo de Análisis

23 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.

24 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.

25 Arquitectura Modelo-Vista-Control
Modelo  información Vista  presentación o interacción con el usuario Control  comportamiento

26 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

27 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.

28 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.

29 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

30 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.

31 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.

32 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

33 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?

34 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.

35 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

36 Hasta aquí para el 1er entregable

37 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.

38

39 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

40 Bibliografía Capitulo 7 del libro “Ingeniería de software orientada a objetos con UML, Java e Internet.