TÓPICOS DE INGENIERÍA

DE SOFTWARE
Arquitectura de Software
AGENDA
 Arquitecturas de software
 Evolución de arquitecturas

 Diseño de software

 Paradigmas de diseño

 Arquitectura vs. Diseño

 Calidades sistémicas

 Patrón

 Framework
¿Han oído hablar de la
Mansión Winchester?
En 1884, la viuda del inventor de los rifles Winchester
compró un terreno e hizo levantar una mansión sin la
participación de ningún arquitecto
Pero…

¿Qué tiene que ver esta

historia con la
Arquitectura de Software?
 Este tipo de situaciones en el contexto del
desarrollo de software, es más común de lo
que debería
 Viéndolo de esa forma…

…un arquitecto de
edificaciones y un arquitecto
de Software enfrentarán los
mismos retos.
ANTES DE INICIAR UN DESARROLLO, DEBEMOS
CONTESTAR ALGUNAS PREGUNTAS
¿Como debo diseñar mi sistema para que sea fácil de
mantener?

¿Cuál será la mejor forma de distribuir mi sistema a los

usuarios?

¿Cuál será la mejor estrategia para distribuir los

componentes de mi sistema y evitar sobrecargas?

¿Cuál es el patrón de diseño más efectivo para el tipo

de sistema que construiré?

¿Cómo debo dividir los componentes para que pueda

reutilizarlos en el futuro?
Entonces…

¿Qué es la Arquitectura de
Software?
ARQUITECTURA DE SOFTWARE
 Es la estructura o estructuras de un sistema de información.
 Los requisitos de atributos de calidad son las principales guías para el diseño de
la arquitectura.
 La Arquitectura de Software tiene que ver con la estructuración de alto nivel de
un sistema en la etapa de diseño.
ARQUITECTURA DE SOFTWARE
 Todo sistema de software tiene una arquitectura; el arquitecto de software es el
responsable de su creación.
 Es la estructura de componentes, conectores, relaciones, principios y pautas que
definen su diseño y evolución en el tiempo.
Pero antes…

…repasemos algunos conceptos

de Arquitectura de Software
MODULARIDAD

Divide y Vencerás
Permite la reutilización de partes.

Facilita el mantenimiento al permitir

corregir o reemplazar partes de la
aplicación, sin requerir un reemplazo
completo
COHESIÓN

Cada componente esta

orientado a cumplir una y solo
una tarea, bien definida y
enfocada.
ACOPLAMIENTO

Hace referencia al grado de

interconexión o dependencia
entre sus componentes.
RELACIONES ENTRE COHESIÓN Y
ACOPLAMIENTO
EVOLUCIÓN DE LA
ARQUITECTURA
Aplicación monolítica.

Cliente-servidor.

Peer-to-peer.

Multi-tier
APLICACIÓN MONOLÍTICA

Son aplicaciones, en la que la

interfaz de usuario, lógica de
procesamiento y el código de
acceso a datos están
combinados en un solo
programa y una sola
plataforma,
EVOLUCIÓN DE LAS ARQUITECTURAS
Aplicaciones Monolíticas
 Interfaces gráficas de usuario (GUI).
 Servicios de presentación, negocios y
persistencia en la misma máquina.
 No hay concurrencia de usuarios.
 Alto acoplamiento entre tiers.
CLIENTE SERVIDOR

Son aplicaciones, que se

comunican por medio de
una red
CLIENTE SERVIDOR
Conexiones dedicadas a BD

Protocolos pesados

Ejecución remota de SQLs

Alta administración

Bajo rendimiento

Alto tráfico de red

Baja accesibilidad
PEER-TO-PEER (P2P)

No existe la noción de
Clientes o Servidores,
todos los nodos son
iguales y actúan tanto
como clientes y servidores
EVOLUCIÓN DE LAS ARQUITECTURAS
Aplicaciones 3 niveles

 Reutilización de lógica de negocio para diferentes clientes o sistemas.

 Mejora la escalabilidad.

 Mejora la flexibilidad.

 Independencia de la base de datos.

EVOLUCIÓN DE LAS ARQUITECTURAS
Aplicaciones N-niveles (clientes livianos)

 Bajo costo de administración de clientes.

 Alta accesibilidad, alta flexibilidad.

 Alta disponibilidad y tolerancia a fallos.

 Alta escalabilidad.

 Independencia de DB
ARQUITECTURA MULTI-TIER O MULTICAPAS

es una arquitectura
cliente-servidor donde la
presentación, el
procesamiento de la
aplicación y la gestión de
datos son procesos
lógicamente separados
EVOLUCIÓN DE LAS ARQUITECTURAS
Multicapas
 Aislamiento de la lógica de aplicaciones en
componentes independientes susceptibles de
reutilizarse después en otros sistemas.
 Distribución de las capas en varios nodos físicos de
cómputo y en varios procesos. Esto puede mejorar el
desempeño, la coordinación y el compartir la
información en un sistema de cliente-servidor.
 Asignación de los diseñadores para que construyan
determinadas capas; por ejemplo, un equipo que trabaje
exclusivamente en la capa de presentación. Y así se
brinda soporte a los conocimientos especializados en
las habilidades de desarrollo y también a la capacidad
de realizar actividades simultáneas en equipo.
EVOLUCIÓN DE LAS ARQUITECTURAS
Sistemas Empresariales
 Las empresas necesitan agilidad en su negocio:
 Los requerimientos cambian continuamente.
 Implementación de nuevos programas o servicios para atraer o
retener clientes.
 Requieren unificar, refina y medir sus procesos de negocio

 Requieren que su infraestructura de IT se pueda adaptar al

cambio, se flexible y tener libertad de escoger nuevas
tecnologías o productos en una relación costo beneficio.
DISEÑO DE SOFTWARE
Después de comprender los requerimientos, el diseño es el mapa
de cómo construir el sistema
Un patrón de diseño identifica un problema común y proporciona
una solución recomendada
Un estándar de diseño es una convención interna y específica para
una organización, para regir sus diseños
ARQUITECTURA VS. DISEÑO
La arquitectura envuelve un conjunto de decisiones estratégicas de diseño,
lineamientos, reglas y patrones que restringen el diseño y la implementación de
un software.
CALIDADES SISTÉMICAS
Definición:
Son propiedades que establecen la calidad de servicio (QoS) que un
sistema expone.
Funcionales:
Referidas a lo que el sistema hace, es decir, aquellas funciones que los
usuarios del sistema pueden observar.
No funcionales:
Definen cómo de bien funciona el sistema: disponibilidad, usabilidad, entre
otros.
CALIDADES SISTÉMICAS
Las calidades sistémicas se dividen en familias:
Manifiestas
Operacionales
Evolutivas
De desarrollo
CALIDADES SISTÉMICAS
Calidades Manifiestas:
Observables por los usuarios del sistema.
Reliability (confiabilidad): Grado de probabilidad de realizar operaciones correctamente.
Availability (disponibilidad): Porcentaje de tiempo que un sistema puede procesar
solicitudes.
Performance (rendimiento): La rapidez y eficacia con la cual el sistema cumple la
petición. Es decir, solicitudes atendidas por unidad de tiempo.
Usability (usabilidad): El grado de facilidad o dificultad en el manejo del sistema.
CALIDADES SISTÉMICAS
Calidades Operacionales:
Relacionadas a la operación del sistema cuando es ejecutado:
Throughput (volumen de trabajo): Cantidad de trabajo hecho por el sistema medido en
operaciones por unidad de tiempo.
Manageability (manejabilidad): Posibilidad de ser Administrado.
Security (seguridad): Prevención de uso no autorizado del sistema y su información.
Supportability (soporte): Esfuerzo necesario para actualizar o reparar el sistema.
Testeability (capacidad de probar): Esfuerzo requerido para identificar y aislar una falla
en el sistema.
CALIDADES SISTÉMICAS
Calidades Evolutivas:
Relacionadas con el comportamiento del sistema cuando es
actualizado.
 Escalability: La habilidad para  Reusability: Esfuerzo ganado en
soportar la calidad de servicio la utilización de componentes
requerida conforme la carga existentes.
aumenta.
 Portability: Esfuerzo ahorrado
 Flexibility: Esfuerzo ahorrado
cuando se migra a una
cuando se hace un cambio de
infraestructura diferente.
configuración.
 Extensibility: Esfuerzo ahorrado  Mantainability: Esfuerzo
para adicionar nuevas ahorrado para revisar y corregir
funcionalidades. errores de diseño.
CALIDADES SISTÉMICAS
Calidades de Desarrollo:

Relacionadas con la construcción del sistema:

Reliability (fiabilidad): Probabilidad o confianza
en que el sistema puede desarrollarse, se ve
reflejado en la facilidad de estimación, planeación y
construcción.
Serviceability (planeabilidad ): Confianza en que
el sistema puede ser planeado en costo y esfuerzo.
RECURSOS DE ARQUITECTURA Y
DISEÑO
Patrón.
Un patrón codifica conocimiento específico acumulado por la
experiencia en un dominio
Un sistema bien estructurado contiene patrones: “Cada patrón
describe un problema que ocurre una y otra vez en nuestro
ambiente, y luego describe el núcleo de la solución a ese problema,
de tal manera que puedes usar esa solución un millón de veces
más, sin hacer jamás la misma cosa dos veces.”
RECURSOS DE ARQUITECTURA Y
DISEÑO
Patrón.
Definición:
Un Patrón describe una solución probada a un problema recurrente de diseño, el cual
ocurre en un contexto.
Existen patrones de:
Arquitectura,
Análisis y diseño.
La definición de arquitectura requiere un proceso basado en el
raciocinio sobre patrones:
Un arquitecto reutiliza patrones para definir la estructura y el comportamiento interno y
externo de un sistema.
RECURSOS DE ARQUITECTURA Y
DISEÑO
Elementos de un patrón:
 Nombre
 Define un vocabulario de diseño
 Facilita abstracción

 Problema
 Describe cuando aplicar el patrón
 Conjunto de fuerzas: objetivos y restricciones
 Prerrequisitos

 Solución
 Elementosque constituyen el diseño (template)
 Forma canónica para resolver fuerzas

 Consecuencias
 Resultados, extensiones
FRAMEWORK
Definición de Framework
 Es un subsistema de software parcialmente construido, de propósito general
para un tipo específico de problema, el cual debe ser instanciado para resolver
un problema en particular.
 Son elementos reutilizables de software que proveen funcionalidades
genéricas enfocadas a resolver cuestiones recurrentes. Existen frameworks
para resolver distintos aspectos de una aplicación; por ejemplo, Java Server
Faces (JSF) es un framework para crear interfaces de usuario en aplicaciones
web.
 Típicamente un framework se construye a partir de patrones de diseño. Los
frameworks imponen patrones de diseño para su uso
FRAMEWORK
Ejemplos de Frameworks:
Tecnológicos: Conceptuales:
 Struts y Java Server Faces (JSF)  Definición de arquitecturas.
para Interfaces Web.
 eTom (enhanced
 Mapeos objeto-relacionales. Telecomunication Operations
 Enterprise Java Beans para Map), es un marco referencial
construcción de servicios de de procesos para la industria de
negocios. las telecomunicaciones.
 Framework de patrones de  RUP como metodología para
diseño para J2EE de Sun definición de procesos de
Microsystems. desarrollo.
 Framework para testing de
performance.
VISTA DE ARQUITECTURA
VISTAS DE ARQUITECTURA
DIAGRAMAS DE UML
Los diagramas expresan gráficamente partes de un

modelo
Use Case State
Diagrama de
Diagrams State
Use Case Diagrams
Use Case
Diagrams
Casos de Uso Diagrams de
Diagrama
Diagrama de
Diagrams Clases
Estados State
State
Diagrams
Diagrams de
Diagrama
Objeto
Estática
Scenario Actividad
Scenario
Diagrams
Diagrama de
Diagrams Component
Actividad Component
Diagrams
Diagramas Diagrama
de
Diagrams
Componentes
Implementación
Interacción
Scenario
Scenario
Diagrams
Diagrama de
Diagrams
Component
Component
Diagrama de Diagrams
Secuencia Diagrama
Diagrams de
Colaboración Despliegue
DIAGRAMAS DE UML
 Modelado estático
Diagrama de casos de uso:
Para comprender el sistema

Diagrama de clases
Para comprender qué hay en el sistema (ejemplo Modelo de Dominio)

 Modelado dinámico
Diagrama de interacción
Para comprender el comportamiento del sistema (interacción entre clases)

Diagrama de transición de estados

Para comprender el comportamiento del sistema (clases aisladas)
ELEMENTOS BÁSICOS DE LA POO
Objeto:
cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los
métodos que controlan dichos datos.
Clases:
familia de objetos con las mismas características.
Métodos:
procedimientos que contienen los objetos y que manipulan los datos
contenidos en éstos.
Mensajes:
solicitud para que se lleve a cabo la operación indicada.
Herencia:
mecanismo mediante el cual una clase adquiere las propiedades de una
clase superior.
MODELO DEL DOMINIO
 El modelo del dominio muestra (a los modeladores) clases conceptuales
significativas en un dominio del problema.
 Idea Clave : “Un modelo del dominio es una representación de las clases
conceptuales del mundo real, no de componentes del software. No se trata de
un conjunto de diagramas que describen clases de software, u objetos de
software con responsabilidad.
 Parte con la descomposición de un dominio de interés en clases conceptuales
individuales u objetos – las cosas de las que somos conscientes -.
 Utilizando la notación UML, un modelo de dominio se representa con un
conjunto de diagramas de clases en los que no se define ninguna operación.
MODELO DEL DOMINIO
Los modelos de dominio pueden mostrar:
• Objetos del dominio o clases conceptuales.
• Asociaciones entre las clases conceptuales.
• Atributos de las clases conceptuales.
MODELO DEL DOMINIO
 Ejemplo

Conceptouuobjeto
Concepto objeto
deldominio
del dominio

Atributos
Atributos

Asociación
Asociación
MODELO DEL DOMINIO
 Los modelos del dominio no son modelos de componentes de software
 Un modelo del dominio , es un representación de las cosas del mundo real del
dominio de interés, no de componentes del software. Por lo tanto, los
siguientes elementos no son adecuados en un modelo de dominio:
 Artefactos de software, como una ventana o base de datos, a menos que el
dominio que se este modelando sea de conceptos de software, como un
modelo de interfaces de usuario grafica.
 Responsabilidades o métodos
MODELO DEL DOMINIO
 “Una clase conceptual es una idea, cosa u objeto”. Más formalmente, una
clase conceptual podría considerarse en términos de un símbolo, intención, y
extensión.

 Símbolo: palabras o imágenes que representan una clase conceptual.

 Intención: la definición de una clase conceptual.
 Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual.
MODELO DEL DOMINIO – CLASES
CONCEPTUALES
Por ejemplo considerar la clase conceptual para el evento de una
transacción de compra.

Venta
Fecha Símbolo del Concepto
hora

“Unaventa
“Una ventarepresenta
representaelelhecho
hechode
de
unatransición
una transiciónde
decompra.
compra.Sucede
Sucede
undía
díayyaauna
unahora”
hora” Intención del concepto
un

Venta-1
Extensión del concepto
Venta-n Venta-2
IDENTIFICACIÓN DE CLASES
CONCEPTUALES
Estrategias para identificar clases conceptuales
1. Utilizar una lista de categorías clases conceptuales.
2. Identificación de frases nominales.
3. Otra excelente técnica para el modelado del dominio es
el uso de patrones de análisis, que son modelos de
dominios parciales existentes creados por expertos.
 IDENTIFICACIÓN DE CLASES – LISTA DE
CATEGORÍAS
Categoría de clases conceptuales Ejemplos (dominio tiendas y Categoría de clases conceptuales Ejemplos (dominio tiendas y
reservas de vuelo) reservas de vuelo)
Organizaciones DepartamentodeVenta,
Objetos tangibles o físicos Registro, Avión CompañiaArea
Especificaciones, diseños, o EspecificaciondelProducto, Hechos Venta, Pago,
descripciones de las cosas DescripciondelVuelo Runión,Vuelo,Colision,Aterrizaje
Procesos (normalmente no se VentadeUnProducto,
Lugares Tienda presentan como conceptos) ReservaUnAsiento
Reglas y políticas PoliticadeReintegro,
Transacciones Venta, Pago, Reserva PoliticadeCancelación

Líneas de la transacción LineadeVenta Catálogos CatalogodeProductos,

CatalogodePiezas
Roles de la gente Cajero, Piloto Registro de finazas, trabajo, Recibo, LibroMayor,
contratos, cuestiones legales ContratoEmpleo,
Contenedores de otras cosas Tienda, Lata, Avión RegistroMantención
Instrumentos y servicio financieros LineadeCredito, Stock
Cosas en un contenedor Articulo, Pasajero
Manuales, documentos, artículos de ListaDeCambiosDePReciosDiarios,
Otros sistemas informáticos o SistemaautorizacionPagoCredito, referencia, libros ManualReparaciones
electromagnéticos ControlTraficoAereo
IDENTIFICACIÓN DE CLASES –
FRASES NOMINALES
 Otratécnica útil es el análisis lingüístico: identificar los nombres y frases
nominales en las descripciones textuales de un dominio, y considerarlos como
clases conceptuales o atributos candidatos.
Escenario Principal de Éxito (Procesar Venta)
1. El cliente llega a un terminal PDV con mercancías
2. El cajero comienza una nueva venta
3. El cajero introduce el identificador del artículo.
4. El sistema registra la línea de la venta y presenta la descripción del articulo, precio y suma parcial. El cajero
repite el paso 3 y 4 hasta que termine
5. El sistema presenta el total con los impuestos calculados
6. El Cajero le dice al cliente el total y solicita el pago
7. El cliente paga y el sistema gestiona el pago
8. El sistema registra la venta completa y envía la información de la venta y el pago al sistema de contabilidad
externo y al sistema de inventario.
9. El sistema presenta el recibo
10. El cliente se va con el recibo y las mercancías (si es el caso)
CLASES CONCEPTUALES DE ESPECIFICACIÓN O
DESCRIPCIÓN
 Deben ser usadas cuando:
 Se necesita la descripción de un articulo o servicio, independiente de la
existencia actual.
 La eliminación de las instancias de las cosas que describen dan como
resultado una perdida de información.
 Reduce información redundante y duplicada.
EJEMPLO
ASOCIACIONES
 Esuna relación entre tipos (o más concretamente instancias de estos tipos)
que indica alguna conexión significativa.

Multiplicidad Nombre Asociación

Flecha dirección
lectura opcional
IDENTIFICACIÓN DE ASOCIACIONES
Categorías Ejemplos Categorías Ejemplos
A es una parte física de B Caja-TPDV
A usa o dirige a B Cajero-TPDV
A es una parte lógica de B VentasLíneadeProducto-Venta
A está físicamente contenido en B TPDV-Tienda, Producto-Estante A se comunica con B Cliente-Cajero

A está contenido lógicamente en B DescripcióndeProducto-Catálogo A se relaciona con una transacción B Pago-Venta

A es una transacción relacionada con Pago-Venta

A es una descripción de B DescripcióndeProducto-Producto
otra transacción B
A es un elemento de línea (o VentasLíneadeProducto-Venta
renglón) en una transacción o A es propiedad de B TPDV-Tienda
reporte B
A se Venta-TPDV
conoce/introduce/registra/presenta
/captura en B
A es miembro de B Cajero-Tienda
A es una unidad organizacional de Departamento-Tienda
B
CARACTERÍSTICAS
 Asignación de nombres a las asociaciones
 Deben comenzar con mayúscula.
 Ladirección por defecto para la lectura de los nombres de la asociación es de
izquierda a derecha o de arriba a bajo.
 Asociación e Implementación
 Duranteel modelo de dominio, una asociación, es una manifestación de que
una relación es significativa en un sentido puramente conceptual – en el
mundo real -. Se pueden definir asociaciones que no existan en la
implementación.
ATRIBUTOS
 Atributo es el valor de datos lógico de un objeto.
 Características

 Los atributos en un modelo de dominio deberían ser preferiblemente,

atributos simples o tipos de datos (boolean, fecha, número, string, hora).
 Serecomienda que se relacionen las clases conceptuales por asociaciones no
con atributos
 Encaso de duda, defina algo como una clase conceptual aparte en lugar de
cómo atributo.
ATRIBUTOS – EVITAR
 No usar atributos a elementos que sean llaves de otros dominios

ClaveAJENA
Clave AJENA
EJEMPLO
ARTEFACTO: CLASE DEL ANÁLISIS
Una clase de análisis representa la abstracción de una o varias clases
y/o subsistemas del diseño del sistema. Esta abstracción posee las
siguientes características:
Una clase de análisis se centra en el tratamiento de los requisitos
funcionales.
Una clase de análisis también define atributos, aunque esos
atributos son de alto nivel, pero normalmente estos pasan hacer
una clase en el diseño.
Las clases del análisis siempre encaja en uno de tres estereotipos
básicos: Interfaz, Control, Entidad.
CLASES ANÁLISIS DEL MODELO DE
ANÁLISIS
CLASE DE INTERFAZ
Las clases de interfaz se utilizan para modelar la interacción entre
el sistema y los actores.
Las clases de interfaz modelan las partes del sistema que dependen
de sus actores, lo cual implica que clasifican y reúnen los
requisitos en los límites del sistema.
Las clases de interfaz representan a menudo abstracciones de
ventanas, formularios, paneles, interfaces de comunicaciones.
CLASE DE INTERFAZ, EJEMPLO:
CLASE DE ENTIDAD
Las clases de entidad modelan información y el comportamiento
asociado de algún fenómeno o concepto, como persona o un
objeto.
Las clases de entidad reflejan la información de un modo que
beneficia a los desarrolladores al diseñar e implementar el sistema,
incluyendo su soporte de persistencia.
Las clases de entidad suelen mostrar una estructura de datos lógica
y contribuyen a comprender de qué información depende el
sistema.
ENTIDADES: CAPTURANDO
ATRIBUTOS
 Permiten capturar aquellos datos que
nos interesa mantener de la entidad
 Representan la estructura interna de los
objetos de la entidad
 Se vinculan con la información de
negocio.
 Determinan el estado interno del objeto
 Sirven de base para el desarrollo de las
responsabilidades adquiridas por los
objetos de la entidad
CLASE DE ENTIDAD, EJEMPLO:
CLASE DE GESTOR
Las clases de control representan coordinación, secuencia,
transacciones y control de otros objetos y se usan con frecuencia
para encapsular el control de un caso de uso en concreto.
Los aspectos dinámicos del sistema se modelan con clases de
control, debido a que ellas manejan y coordinan las acciones y los
flujos de control principales, y delegan trabajo a otros objetos.
CLASE DE CONTROL, EJEMPLO:
MODELADO DINÁMICO. PROPÓSITO
Captar el comportamiento de los objetos identificados en el
modelo de clase.
Identificar los elementos básicos del comportamiento:
 Eventos.
 Estados.
 Transiciones de estados.
 Funciones (acciones, actividades, servicios).

Completar el diagrama de clases.

DIAGRAMAS DE INTERACCIÓN
Los objetos interactúan para realizar colectivamente los
servicios ofrecidos por las aplicaciones. Los diagramas de
interacción muestran cómo se comunican los objetos en
una interacción
Existen dos tipos de diagramas de interacción:
el Diagrama de Colaboración y el Diagrama de
Secuencia
DIAGRAMAS DE INTERACCIÓN
El Diagrama de Secuencia es el más adecuado para observar la
perspectiva cronológica de las interacciones.
El Diagrama de Colaboración ofrece una mejor visión espacial
mostrando los enlaces de comunicación entre objetos.
El Diagrama de Colaboración puede obtenerse automáticamente a
partir del correspondiente Diagrama de Secuencia (o viceversa)
DIAGRAMA DE SECUENCIA
Los Diagramas de Secuencia y de Colaboración son usados para
describir gráficamente un caso de uso o un escenario.
Un Diagrama de Secuencia muestra los objetos de un escenario
mediante líneas verticales y los mensajes entre objetos como
flechas conectando objetos.
Los mensajes son dibujados cronológicamente desde arriba hacia
abajo.
Los rectángulos en las líneas verticales representan los periodos de
actividad de los objetos.
DIAGRAMA DE SECUENCIA
Hay un (al menos) diagrama de secuencia para cada caso de uso.
Muestra la secuencia de mensajes entre objetos durante un
escenario concreto.
Cada objeto viene dado por una barra vertical.
El tiempo transcurre de arriba abajo.
Cuando existe demora entre el envío y la atención se puede indicar
usando una línea oblicua.
DIAGRAMAS DE SECUENCIA:
NOTACIÓN
Nombre Clase Clase

Mensaje u operación

Barra de sincronización temporal

Actor
DIAGRAMA DE SECUENCIA
C1 C2

Operación
iniciada por el
actor Operación de
C2 invocada
por C1
DIAGRAMA DE SECUENCIA

:WInPréstamos :Socio :Video :Préstamo

: Encargado

prestar(video, socio)
verificar situación socio

verificar situación video

registrar préstamo

entregar recibo
PROCESO DE ELABORACIÓN
Identificación • Situaciones en la que
queremos ver cómo
de los funciona el sistema
escenarios para resolver algo

Identificación • Es decir,
identificación de
de los eventos quien demanda que
externos empiece un escenario

• Diagramas de
Modelado de secuencia o
interacciones colaboración
EJEMPLO: UNA HISTORIA
EJEMPLO: UNA HISTORIA
Escenario:
El reloj del sistema le indica al sol que debe brillar
El sol le dice al reloj que suene
El reloj despierta a la persona
La persona apaga el reloj
La persona se vuelve a dormir

Actor: reloj del sistema

EJEMPLO: UNA HISTORIA
DIAGRAMA DE COLABORACIÓN VS
SECUENCIA
DIAGRAMA DE COLABORACIÓN VS
SECUENCIA
La diferencia es que el diagrama de secuencia muestra las
interacciones con la dimensión del tiempo, mientras que el
diagrama de colaboración muestra en un contexto y organización
general, cómo los objetos interactúan desde el punto de vista del
espacio.
DIAGRAMA DE COLABORACIÓN VS
SECUENCIA
DIAGRAMA DE COLABORACIÓN VS
SECUENCIA
DIAGRAMA DE SECUENCIA
Crear un diagrama de secuencia para hacer el retiro
mediante el cajero (persona), de una de las oficinas de una
entidad financiera; para ello cuenta con los siguientes
elementos: cliente, cajero, tarjeta, lector de tarjeta y
cuenta.
DIAGRAMA DE SECUENCIA
DIAGRAMA DE SECUENCIA -
EJERCICIO
 Proceso: Emisión de proforma.
 Requerimiento: Identificar las instancias u objetos enunciados, así como los
mensajes que interactúan y luego dibujar el diagrama de secuencia.
 Descripción: El diagrama de interacción a crear permitirá graficar los
mensajes que se envían para la emisión de una proforma.
 El proceso se inicia cuando el cliente entrega el pedido al vendedor, este
ultimo consultara los datos al catalogo de productos. A continuación el
vendedor lee los datos para luego crear la proforma, el mismo vendedor
calcula los descuentos e impuestos, por último el vendedor entrega la
proforma.
DIAGRAMA DE SECUENCIA -
EJERCICIO
DIAGRAMA DE SECUENCIA Y DE
COLABORACIÓN (COMUNICACIÓN)
La realización de los casos de uso se plasman en dos tipos de
diagramas:
Diagrama de secuencia, muestra la interacción de los objetos en el
tiempo a través de mensajes.
Diagrama de colaboración (comunicación), muestra la distribución
estática de los objetos unidos por responsabilidades.
Los diagramas de secuencia y de colaboración son Isomorfos.
Un diagrama de secuencia se puede transformar mecánicamente en
un diagrama de colaboración. Un diagrama de colaboración se
puede transformar mecánicamente en un diagrama de secuencia.
DIAGRAMA DE SECUENCIA:

Realización del caso de

uso:
Ingresar al Sistema

Diagrama de secuencia
DIAGRAMA DE SECUENCIA:

Realización del caso de

uso:
Reservar película

Diagrama de secuencia
DIAGRAMA DE DISEÑO – DIAGRAMA
DE SECUENCIA
Un diagrama de secuencia es un diagrama que nos
representa el curso o flujos que se desarrollan dentro de
cada caso de uso, contiene:
• Objetos con sus “líneas de vida”
• Mensajes intercambiados entre objetos en una secuencia
ordenada
DIAGRAMA DE SECUENCIA
 Eldiagrama de secuencias consta de objetos, representados del modo usual:
rectángulos con nombres subrayados, estímulos (también conocidos como
mensajes) representados por líneas continuas con una punta de flecha y el
tiempo representado por una progresión vertical.
ELABORACIÓN
1. Los objetos se colocan cerca de la parte superior del diagrama de izquierda
a derecha y se acomodan de manera que simplifiquen el diagrama.
2. La extensión que está debajo (y en forma descendente) de cada objeto será
una línea discontinua conocida como la línea de vida de un objeto.
3. Junto con la línea de vida de un objeto se encuentra un pequeño rectángulo
conocido como activación, el cual representa la ejecución de una operación
que realiza el objeto. La longitud del rectángulo se interpreta como la
duración de la activación.
ELABORACIÓN
4. Los envíos de mensajes se representan mediante flechas horizontales que
unen la línea de vida del objeto emisor con la línea de vida del objeto
destinatario. En cada flecha se pone el nombre del acontecimiento que
provoca el envío del mensaje, y se puede acompañar de datos entre
paréntesis.
5. Los tipos de mensajes que pueden existir son:
a) Simple: es la transferencia del control de un objeto a otro
b) Síncronos: son los más utilizados. El emisor del mensaje debe esperar a que el
destinatario finalice el método mencionado antes de continuar su actividad.
c) Asíncrono: el emisor no espera al destinatario para poder realizar otras acciones
6. El tiempo se representa y controla en la línea vertical.
DIAGRAMA DE SECUENCIA
 La creación y destrucción de objetos se  La recursividad ocurre cuando un objeto se
representa mediante: envía a si mismo un mensaje y se representa
por:
EJEMPLO
DIAGRAMA DE CLASES
Este diagrama es una estructura estática que describe la estructura
de un sistema mostrando las clases del sistema, sus atributos,
operaciones (o métodos), y las relaciones entre los objetos
Sus elementos son:
 Clases
 Relación entre clases
EJEMPLO
DIAGRAMAS DE ARQUITECTURA –
DIAGRAMA DE PAQUETES
• Representa las dependencias entre los paquetes que componen un
modelo. Es decir, muestra cómo un sistema está dividido en
agrupaciones lógicas y las dependencias entre esas agrupaciones.
• Los paquetes están normalmente organizados para maximizar la
coherencia dentro de cada paquete y minimizar el acoplamiento
externo entre los paquetes, los paquetes pueden asignarse a un
individuo o a un equipo, y las dependencias entre ellos pueden
indicar el orden de desarrollo requerido
ELEMENTOS
Estos diagramas contienen dos tipos de elementos:
• Paquetes: Un paquete es una agrupación de elementos, bien sea
casos de uso, clases o componentes. Los paquetes pueden
contener a su vez otros paquetes anidados que en ultima instancia
contendrán alguno de los elementos anteriores.
• Dependencias entre paquetes: Existe una dependencia cuando un
elemento de un paquete requiere de otro que pertenece a un
paquete distinto. Es importante resaltar que las dependencias no
son transitivas.
EJEMPLO
RESUMEN
En esta sesión hemos aprendido:
Diseño de software
Arquitecturas de software
Evolución de arquitecturas
Patrón
Framework
Diagramas de Interacción
Diagramas de Secuencia
Ejercicio prácticos.