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.