Análisis y diseño de sistemas

1. DISEÑO DE SISTEMAS
Diagrama de Comunicación oColaboración,
Modelado de Base de Datos
SESIÓN 12
Diagramade Secuencia,
Docente: Mgtr. Allende Tauma Renzo R.
CIP: 228248

2. Metodología RUP, en resumen
• Un proyecto es exitoso cuando cumple con el tiempo, alcance y
costo.
• Un proyecto informático es el esfuerzo temporal que se lleva a
cabo para crear un producto y/o servicio relacionado al
tratamiento de la información.
• Una metodología dice qué hacer, cómo y con quienes.
• RUP es configurable y se puede adaptar al grado de complejidad
del modelo de proceso de desarrollo de software utilizado por la
organización.
• RUP está compuesto por 4 etapas y 9 disciplinas.
• RUP es una guía sobre como usar efectivamente el UML.
Conocimientos previos

3. ¿Para que sirven los
Artefactos?
RUP en cada una de sus
fases realiza una serie de
artefactos que sirven para
comprender mejor tanto el
análisis como el diseño del
sistema.
Conocimientos previos

4. Conocimientos previos

5. Datos/Observaciones
ANÁLISIS DE CASOS DE USO
Todas las clases de análisis Requisitos especiales sobre la
realización de un caso de uso
-----
----------
----------
----------
----------
----------
----------
----
ECU
comportamiento de los casos
de uso entre los objetos de
análisis que interactúan
Establecer detalles de la relación necesaria entre clases de análisis
para lograr la funcionalidad descrita en el CU
Conocimientos previos

6. Datos/Observaciones
REALIZACIÓN DE CASOS DE USO
Una realización de caso de uso describe
cómo un caso de uso en particular es
modelado, primero en el modelo de
análisis y después en el modelo de
diseño, en términos de objetos
colaboradores.
Conocimientos previos
Otros diagramas

7. Datos/Observaciones
¿CÓMO ENCONTRAR CLASES DE ANÁLISIS?
ECU
Se identifican por CU:
- Cero o más clases de interfaz
- Una clase control
- Una o más clases entidad
Conocimientos previos

8. Datos/Observaciones
CLASES DE ANÁLISIS
• Son clases estereotipadas
para crear modelos ideales de
objetos.
• Se basa en el patrón MVC
(Model-View-Controller), que
define clases enfocadas a la
separación de
responsabilidades.
Conocimientos previos

9. Datos/Observaciones
17
Ejemplo:
El CU “Procesar Facturación” envía información a un Sistema de
Facturación externo.
Describe una interacción entre el sistema con los
usuarios y con otros sistemas (Dispositivos o
Software). Pueden modelar formularios, protocolos o
APIs.
CLASE BOUNDARY [Interfaz]
Conocimientos previos

10. Datos/Observaciones
Ejemplo:
En un paquete de análisis denominado Evaluación se
ubican los CU: “Evaluar empleado”, “Procesar
evaluación de desempeño” y “Consultar estadísticas de
Evaluaciones”. La clase control que coordine el trabajo
de cada uno es:
Modela la coordinación, secuencia, transacciones y
control de otros objetos.
Todos los CU ubicados en un paquete de análisis
comparten la misma clase control.
CLASE CONTROL [Control]
Conocimientos previos

11. Datos/Observaciones
Ejemplo:
En el caso de uso “Mantener empleados” en el cual se
puede registrar, modificar o desactivar empleados es
evidente que la información que debe ser manipulada es
del empleado.
Modela información o comportamiento que
posee una vida larga en el sistema.
Estas clases sufren un proceso de refinamiento a
medida que se ubica a la misma clase entidad
dentro de distintas realizaciones de caso de uso.
CLASE ENTITY [Entidad]
Conocimientos previos

12. DIAGRAMA DE CLASES DE ANÁLISIS
Conocimientos previos

13. Datos/Observaciones
DIAGRAMA DE COMUNICACIÓN / COLABORACIÓN
Conocimientos previos
*Desde un diagrama de Secuencia con F5 generas su diagrama de colaboración.

14. Datos/Observaciones
DIAGRAMA DE SECUENCIA
• Se usan para representar el flujo de
trabajo, el paso de mensajes y cómo
los elementos en general cooperan a
lo largo del tiempo para lograr un
resultado.
• Es una representación estructurada de
comportamiento como una serie de
pasos secuenciales a lo largo del
tiempo.

15. Datos/Observaciones
DIAGRAMA DE SECUENCIA
CARACTERÍSTICAS
• Representa una interacción, un conjunto de comunicaciones entre objetos
organizados visualmente por orden temporal.
• Posee dos dimensiones:
• La dimensión vertical que representa el tiempo.
• La dimensión horizontal que representa los objetos que participan en la interacción.

16. Datos/Observaciones
DIAGRAMA DE SECUENCIA
ELEMENTOS
• Objetos:
• Se coloca en un línea horizontal
imaginaria.
• Se representan por rectángulo
con nombre subrayado.
• Foco de control:
• Símbolo que muestra el periodo
de tiempo durante el cual un
objeto está realizando una
acción.

17. DIAGRAMA DE SECUENCIA
ELEMENTOS
• La línea de vida:
• Se representa por una línea
vertical punteada debajo del
objeto.
• Mensaje:
• Se representa por una línea
dirigida .
• Muestra la progresión al próximo
paso de la secuencia.

18. Datos/Observaciones
DIAGRAMA DE SECUENCIA
TIPOS DE MENSAJE
• Mensaje asíncrono:
• Se envía y sigue procesando sin esperar la
respuesta.
• Mensaje síncrono:
• Secuencia a ser completada antes de salir
del nivel. Espera respuesta.
• Retorno de mensaje:
• El receptor de un mensaje anterior devuelve
el foco de control al emisor

19. Datos/Observaciones
DIAGRAMA DE SECUENCIA

20. Datos/Observaciones
DIAGRAMA DE SECUENCIA
USOS
• Los diagramas de secuencia representan objetos que deben asociarse a las clases:
• Para un diagrama de secuencia de análisis deberá asociarse a las clases de
análisis boundary, control y entity.
• Para un diagrama de secuencia de diseño deberá asociarse a las clases de
diseño (según lenguaje de programación escogido).

21. Datos/Observaciones
DIAGRAMA DE COMUNICACIÓN
• Los diagramas de comunicación
enfatizan los aspectos estructurales de
una interacción.
• Se usan para visualizar relaciones
inter-objetos mientras en los
diagramas de secuencia son más
efectivos para visualizar
procesamiento a lo largo del tiempo.

22. Datos/Observaciones
DIAGRAMA DE COMUNICACIÓN
ELEMENTOS:
• Lifeline:
• Es un participante
individual de una
interacción, se
representa por una
entidad con nombre
subrayado con un
objeto asociado a una
clase.

23. Datos/Observaciones
DIAGRAMA DE COMUNICACIÓN
ELEMENTOS:
• Conexión:
• Se representa como
una línea que une
íconos de objetos.
• Indica que existe un
camino para establecer
comunicación entre los
objetos conectados

24. Datos/Observaciones
DIAGRAMA DE COMUNICACIÓN
ELEMENTOS:
• Mensaje:
• Se representa como una
flecha apuntando desde el
objeto cliente al objeto
proveedor.
• El nombre del mensaje
con una línea opcional de
parámetros y/o un valor de
regreso de datos.
• El número de secuencia
opcional que muestra el
orden relativo con el cual
son enviados los
mensajes.

25. Datos/Observaciones
DIAGRAMA DE COMUNICACIÓN
USOS:
• Los diagramas de comunicación representan objetos que deben asociarse a las
clases.
• Para un diagrama de comunicación de análisis, deberán asociarse a las clases
de análisis: boundary, control y entity.
• Para un diagrama de comunicación de diseño deberán asociarse a las clases
de diseño (según lenguaje de programación escogido).

26. Datos/Observaciones
MODELO FÍSICO DE DATOS
5
Es la última etapa de la metodología de diseño de bases de datos que describe cómo
se implantará la base de datos en el mundo real, es decir, a nivel de la plataforma de
hardware, software, conectividad de redes, sistema operativo, dll’s y otros
componentes.
Contiene las tablas de la BD del sistema y es específico a un SGBD. El paso de un
modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases
de datos que se desea emplear, incluyendo características como:
• Detalles acerca del indexamiento, integridad referencial,
restricciones, tipos de datos, etc
• Detalles y variaciones de las versiones
• Parámetros de configuración
• Data Definition Language (DDL)

27. Datos/Observaciones
IMPORTANCIA DEL DISEÑO FÍSICO
• Hacer el diseño físico de la base de datos no sólo es modelar estructuras de
tablas, columnas y relaciones.
• El diseño físico representa la implantación, para lo cual modela cómo y dónde la
data será almacenada.
• Es típico que en el diseño que se cree uno o más nodos para que alojen la base de
datos y luego instalar en ellos los componentes del DBMS.
• Si la base de datos reside en distintas instancias de DBMS, se podrán asignar
paquetes (<<schema>>) de tablas a un DBMS en particular para indicar donde
residirá la data respectiva.
• Se afina mediante la definición de índices, parámetros de almacenamiento,
usuarios, disparadores.

28. Datos/Observaciones
SISTEMAS DE GESTIÓN DE BASES DE DATOS

29. Datos/Observaciones
DICCIONARIO DE DATOS
Es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos
elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer
los requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos
se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema.
Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario
guarda los detalles y descripciones de todos estos elementos

30. Datos/Observaciones
HERENCIA EN BASE DE DATOS RELACIONAL
Vamos a trabajar con la siguiente jerarquía de herencia con tres clases: Persona, Cliente,
Empleado. La clase Persona es abstracta y las otras son clases concretas que extienden de la
primera. De un Cliente vamos a saber su número de tarjeta de crédito y de un empleado vamos a
saber la cuenta bancaria donde se depositan su sueldo.

31. Datos/Observaciones
UNA TABLA POR CADA CLASE
Se crean tres tablas: personas, clientes y empleados. Cada tabla contendrá los campos de cada
clase. Los únicos campos que se repetirán serán los relativos a las claves primarias

32. Datos/Observaciones
UNA TABLA POR CLASE CONCRETA
Se crean dos tablas: Empleado y clientes. Cada tabla contendrá los campos respectivos.

33. Datos/Observaciones
UNA TABLA PARA LA JERARQUÍA DE HERENCIA Y
UNA TABLA TIPO
Con esta estrategia tendríamos una tabla persona y una tipo para manejar restricción
referencial:

34. Datos/Observaciones
RESUMEN HERENCIA
• Lo más recomendable es utilizar la segunda o la tercera estrategia. Elegir entre ellas
dependerá de las consultas que se han de hacer a la base de datos. Si por ejemplo en
ningún momento hacemos una consulta que involucre tanto a clientes y empleados, quizá lo
mejor será tener una tabla por cada clase concreta. Si por el contrario es común hacer
listados que involucren a ambas clases, entonces lo mejor será utilizar una sola tabla y la
tabla tipo.

35. Datos/Observaciones
AUDITORIA EN BASE DE DATOS
• Consiste en el control de acceso, de actualización, de integración y calidad de los datos.
• Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos
a la información almacenada en la base de datos incluyendo la capacidad de determinar:
o Quien accede a los datos
o Cuando se accedió a los datos
o Desde que tipo de dispositivo/aplicación
o Cual fue la sentencia SQL ejecutada
o Cual fue el efecto del acceso a la BD.

36. OBJETIVOS DE LA AUDITORIA EN BD
• Mitigar los riesgos asociados con el manejo inadecuado de los datos
• Apoyar el cumplimiento regulatorio.
• Satisfacer los requerimientos de los auditores
• Evitar acciones criminales
• Evitar multas por incumplimiento

37. Datos/Observaciones
IMPORTANCIA DE LA AUDITORIA BD
• Toda la información financiera de la organización reside en bases de datos y deben existir
controles relacionados con el acceso a las mismas.
• Se debe poder demostrar la integridad de la información almacenada en las bases de datos.
• Las organizaciones deben mitigar los riesgos asociados a la pérdida de datos y a la fuga de
información.
• La información confidencial de los clientes son responsabilidad de las organizaciones.
• Los datos convertidos en información a través de bases de datos y procesos de negocios
representan el negocio.
• Las organizaciones deben tomar medidas mucho más allá de asegurar sus datos. Deben
monitorearse perfectamente a fin de conocer quién o qué les hizo exactamente: qué, cuándo
y cómo

38. Datos/Observaciones
TÉCNICAS DE AUDITORÍA
• Auditoría nativa de base de datos.
• Añadir campos de auditoría a una tabla.
• Triggersy tablas espejo
• Creación de procedimientos almacenados

39. •Seguimiento y consultas
SEGUIMIENTO DE AVANCES

40. Referencia Bibliográfica