La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


Presentación del tema: "Gloria Lucia Giraldo G. Escuela de Sistemas Semestre II de 2009 Curso de Diseño y Construcción de Productos de Software CLASE 2."— Transcripción de la presentación:

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

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 ACTOR # cédula * nombre * apellido o nomArtístico ACTUACION * rol O premio ESTUDIO #Identificador *nombre PELICULA # código * titulo * año * duración producida en lugar de realización de contratado para depara originadora 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 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 Actor recomienda a Recomendado por

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 CFs 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: 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 Entidad (Información) Control (Comportamiento) Borde (Interfaz) estereotipo 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 > Nombre de Clase1 > Nombre de Clase2 > Nombre de Clase3 Nombre de Clase1Nombre de Clase2Nombre de Clase3 Dos formas: (a) (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 XCaso de uso Y

36 Hasta aquí para el 1 er 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.


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

Presentaciones similares


Anuncios Google