Análisis y diseño de sistemas

1. DISEÑO DE SISTEMAS
Diagrama de Componentes
Diagrama de Despliegue
Docente: Mgtr. Allende Tauma Renzo R.
CIP: 228248
SESIÓN 13

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

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

7. DIAGRAMA DE CLASES DE ANÁLISIS
Conocimientos previos

8. 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.
Conocimientos previos

9. 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.
Conocimientos previos

10. 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).
Conocimientos previos

11. 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.
Conocimientos previos

12. 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
Conocimientos previos

13. 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.
Conocimientos previos

14. 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
Conocimientos previos

15. Datos/Observaciones
ARQUITECTURA DE SOFTWARE
• “La arquitectura del software está compuesta por la estructura de los componentes de
un programa o sistema, sus interrelaciones, y los principios y reglas que gobiernan su
diseño y evolución a lo largo del tiempo”.
David Garlan y Deway Perry 1995
• “La arquitectura del software es la organización fundamental de un sistema encarnada
en sus componentes, las relaciones entre ellos y el entorno, y los principios que
dirigen su diseño y evolución”.
IEEE Std 1471-2000
Conocimientos previos

16. Datos/Observaciones
ARQUITECTURA DE SOFTWARE
DEFINICIÓN
• “Estructura de un sistema a grandes rasgos, formada por componentes y relaciones
entre ellos”.
Conocimientos previos

17. Datos/Observaciones
ARQUITECTURA DE SOFTWARE
Conocimientos previos

18. Datos/Observaciones
ARQUITECTURA DE SOFTWARE - IMPORTANCIA
Las representaciones de la
arquitectura del software permiten
la comunicación entre
stakeholders
Muchos stakeholders están interesados
en la arquitectura
La arquitectura resalta las
decisiones iniciales
relacionadas con el diseño
Representa un modelo relativamente
pequeño, de la forma en que un sistema
se estructura y como sus componentes se
entienden entre sí
3 Razones Claves de la importancia de la arquitectura
Conocimientos previos

19. Datos/Observaciones
ARQUITECTURA MONOLÍTICA
1. Mainframes de gran tamaño.
• Superficie de 160 m2, Peso 30 toneladas,
• Procesamiento de 30.000 instrucciones/seg.
2. Sistemas operativos propietarios.
3. Solo texto.
4. Servicios de presentación, negocios y persistencia en
la misma máquina
5. Terminales “Tontas” teclado y pantalla que se
conectan físicamente a un Mainframe.
Ejemplo Cobol y RPG
Conocimientos previos

20. Datos/Observaciones
ARQUITECTURA CLIENTE SERVIDOR 2 CAPAS
1. Disminución del tamaño de los Mainframes que empezaron a ser
llamados Server.
2. Fortalecimiento de las redes LAN.
3. Alto tráfico de red.
4. Conviven diferentes sistemas operativos
5. Los servidores usaban frecuentemente Unix.
6. Los clientes usaban frecuentemente Windows.
7. Conexiones dedicadas a BD.
8. Alta administración.
9. Bajo rendimiento
10. Baja accesibilidad
Ejemplo Informix-4gl. Visual basic 4
.
Conocimientos previos

21. Datos/Observaciones
ARQUITECTURA CLIENTE SERVIDOR 3 CAPAS
1. Disminución del costo y masificación de los computadores.
• Superficie de 217mm2
• 5.300 MTOPS(“Millions of theoretical operations per
second)
1. Lógica de negocios en BD (store procedures)
2. Aparición comercial de Internet.
3. Fortalecimiento de las redes WAN.
4. Mejora en rendimiento.
5. Alta administración
6. Baja portabilidad
7. Conviven diferentes maquinas, sistemas operativos y
protocolos de comunicación.
8. Primeras aplicaciones en java para internet (Jsp y Servlets)
Conocimientos previos

22. Datos/Observaciones
ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
Cluster de
Servidores de
Aplicaciones
Aplicaciones
Legadas
Servidor de
Procesos
(BPM)
Base de
Datos
Sistema
Batch
Portal de
Servicios Integrados
La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones
independientes de manera que desde la red pueda accederse a sus funcionalidades,
las cuales se ofrecen como servicios.
Conocimientos previos

23. Datos/Observaciones
ARQUITECTURA JEE
Plataforma
Entorno Hardware o Software donde se ejecuta un programa
Plataforma Java
Basada solo en Software No es un hardware específico
Es una máquina virtual encargada de la ejecución de aplicaciones, y un conjunto de bibliotecas estándar
que se ejecutan en varios sistemas Operativos y Hardware
Componentes
Lenguaje Maquina Virtual Librerías/Bibliotecas
Conocimientos previos

24. Datos/Observaciones
MODELO MVC
Conocimientos previos

25. Datos/Observaciones
Analista de sistemas.- Organizar los requisitos y entender los
riesgos y limitaciones
Usuario Final o Cliente.- lo utilizan para entender lo que esta
comprando
Diseñadores.-lo utiliza para comprender la arquitectura planteada y
los limites del diseño.
Arquitectos.-Lo utilizan para identificar los puntos de reusó y la
evolución del software.
Otras organizaciones de desarrollo(software abierto) .- lo utilizan
para comprender cómo interactuar con él.
Gerente de Proyecto.- Lo utiliza para organizar el equipo y el plan
de desarrollo.
Conocimientos previos
ROLES

26. Datos/Observaciones
Conocimientos previos

27. Datos/Observaciones
Conocimientos previos
Product Owner.- Tiene la visión del negocio y
conoce a detalle requerimientos del producto
que se debe construir, lo que conlleva a ser el
líder en cuanto a la toma de decisiones del
desarrollo del producto.
ScrumMaster.- Es el respondable de que
todos los involucrados entiendan y adopten
los valores, principios y preacticas de
SCRUM.
Development Team.- Responsable del diseño,
cosntruccion y prueba del producto.

28. Datos/Observaciones
FASES DE LA ARQUITECTURA
3. Diseño de componentes
2. Selección de patrones de diseño (DAO - DTO- MVC)
1. Elección del estilo arquitectónico (¿Capas?)
Conocimientos previos

29. Conocimientos previos

30. Datos/Observaciones
MODELO DE IMPLEMENTACIÓN
• Identifica los componentes físicos de la
implementación para que puedan
comprenderse y gestionarse mejor.
• Define las principales unidades de
integración que se pueden versionar,
desplegar y reemplazar separadamente.

31. Datos/Observaciones
USO
• En el entorno de programación, una implementación está compuesta por elementos
de implementación, que incluyen los siguientes elementos organizados en
directorios:
• Archivos de código fuente.
• Archivos binarios.
• Archivos de datos.

32. Datos/Observaciones
DIAGRAMA DE COMPONENTES
• Un diagrama de componentes muestra la organización y las dependencias entre
un conjunto de componentes.

33. Datos/Observaciones
COMPONENTE
• Los componentes representan todos los tipos de elementos de software que entran
en la fabricación de aplicaciones informáticas.
• Un componente de software es una parte física de un sistema, y se encuentra en la
computadora, no en la mente del analista.
• Un componente puede ser:
• Una tabla
• Un archivo de datos
• Un archivo ejecutable
• Una biblioteca de vínculos dinámicos
• Documentos.

34. Datos/Observaciones
COMO NOMBRAR UN COMPONENTE
• Recomendaciones para nombrar un componente:
• Se utiliza un sustantivo o conjunto de caracteres
• Puede estar formado por letras y números.
• Corresponde con el nombre del archivo al que representa.
• Debe incluir la extensión del archivo asociado al componente de modelado.
• Opcionalmente, puede incluir etiquetas como versión o autor.

35. Datos/Observaciones
NOTACIÓN UML
• UML 1.X: El símbolo principal es
un rectángulo que tiene otros 2
sobrepuestos en su lado
izquierdo.
• UML 2.X: Es representado por
un rectángulo con un ícono de
componente en la esquina
superior derecha.

36. Datos/Observaciones
NECESIDAD DEL DIAGRAMA
Necesidad del diagrama:
• Los clientes puedan ver la estructura del sistema finalizado.
• Los desarrolladores deben contar con una estructura con la cual trabajar en
adelante.
• Quienes escriban las notas técnicas y la documentación, puedan entender de
qué escribirán.
• El equipo del proyecto se alista para volver a utilizar los componentes
(reutilización).

37. Datos/Observaciones
DIAGRAMA DE COMPONENTES
• Un diagrama de componentes muestra la organización y las dependencias entre
un conjunto de componentes.

38. Datos/Observaciones
DIAGRAMA DE COMPONENTES
• Un diagrama de componentes muestra la organización y las dependencias entre
un conjunto de componentes.

39. Conocimientos previos

40. Datos/Observaciones
MODELO DE DESPLIEGUE
• Describe las actividades asociadas al garantizar que el producto de software esté
disponible para los usuarios.
• Describe tres modalidades de despliegue del producto:
• Instalación personalizada.
• Oferta de producto “comercializable”
• Acceso al software a través de internet

41. Datos/Observaciones
DIAGRAMA DE DESPLIEGUE
• Muestran la configuración de los distintos elementos físicos que forman parte de un sistema
y la distribución de los programas ejecutables sobre estos elementos

42. Datos/Observaciones
DIAGRAMA DE DESPLIEGUE: ELEMENTOS
• Muestran la configuración de los distintos elementos físicos que forman parte de un sistema
y la distribución de los programas ejecutables sobre estos elementos

43. Datos/Observaciones
NODOS
• Cada parte física en donde corren los componentes
• Propiedades:
• Nombre
• Una descripción que proporciona información sobre el procesador, capacidad de
almacenamiento, capacidad de memoria entre otros.
• Una lista de los procesos y hebras que se ejecutan en el procesador.
• Una lista de las unidades de despliegue que se instalarán en el nodo.

44. Datos/Observaciones
CONEXIONES
• La conexión entre nodos, se representa por una relación de asociación.
• Los conectores pueden tener información asociada en relación con la capacidad o ancho de
banda del conector.
• Notación: línea continua.

45. Datos/Observaciones
DIAGRAMA DE DESPLIEGUE
• Modela la topología del
hardware sobre el cual correrá
la aplicación.
• Especifica el hardware físico
sobre el cual, el sistema de
software se ejecutará y
también especifica cómo el
software se despliega en ese
hardware.

46. Datos/Observaciones
DIAGRAMA DE DESPLIEGUE
• Modela la topología del
hardware sobre el cual correrá
la aplicación.
• Especifica el hardware físico
sobre el cual, el sistema de
software se ejecutará y
también especifica cómo el
software se despliega en ese
hardware.

47. Datos/Observaciones
DIAGRAMA DE DESPLIEGUE

48. EXPOSICIÓN FINAL [En informe]:
ACTIVIDAD Semana 14/15
Realizado en 2 fechas: 10/07/21 y 17/07/21
Se aplica "Rubricas".
Estas estan ubicadas en el
modulo Sesion 14
El INFORME terminado debe ser subido en
la BlackBoard antes de el 09/07/21 a las
23:59 pm

49. ACTIVIDAD Semana 13
[PC] Ubicado en el Blackboard, Modulo "Sesión 13/Act. de Evaluación"

50. Referencia Bibliográfica