Diseño y Arquitectura de Software

Unidad:
Introducción a la Arquitectura de Software

Docente: Alfredo Asmat Ramón

 Logro

El estudiante formula un informe descriptivo sobre los

requerimientos de un producto de software para las
necesidades de los Stakeholders, aplicando un lenguaje de
modelado como UML y un proceso de desarrollo en la
herramienta IBM RSA; definiendo la Visión del Negocio, modelo
de casos de Uso y prototipos visuales.

Importancia
Es fundamental poder manejar los conceptos de arquitectura
para poder realizar una correcta implementación de un sistema
mantenible.
 Contenido general

• Introducción al diseño y la Arquitectura de Software

• Principios y procesos en la Arquitectura de Software
• Diagramas UML orientados a la Arquitectura de Software.
Introducción al diseño y la Arquitectura de
Software
• Arquitectura de Software
• Tipos de Arquitectura de Software
Rol del Arquitecto de Software etapa de análisis y diseño
Ingeniero de Software etapa de implementación
Qué es la Arquitectura de Software?
Niveles de Abstracción de
Arquitectura de Software
Arquitecturas Desordenadas vs Ordenadas
¿Qué es una mala arquitectura?

• Compleja
• Incoherente
• Rígida
• Frágil
• No se puede Probar
• No mantenible
¿Qué es una buena arquitectura?

• Simple
• Comprensible
• Flexible
• Emergente
• Se puede Probar
• Mantenible
¿Qué es una arquitectura clara?

La arquitectura está diseñada

para los usuarios no para los
arquitectos … o las máquinas.
¿Qué es una arquitectura clara?
¿Por qué invertir en una buena arquitectura?

Costo / Beneficio
Minimizar el Costo
Maximizar el valor
Maximizar el Retorno
¿Por qué invertir en una buena arquitectura?

Enfocada en lo esencial
Construida para lo necesario
Optimizada para ser mantenible
Decisiones

• Contexto es el rey
• Las decisiones son
consensuadas
• Alineadas con el negocio
• Usa el mejor juicio
Centrado en el dominio
Centrado en el dominio
Clásico 3 Capas - Centrado en la Base Datos
Centrado en la Base Datos vs Centrado en el Dominio
La principal preocupación de los arquitectos es asegurar que la
casa sea usable, y no que sea hecha con ladrillos.
Esencial vs Detallista

Espacio es esencial
Usabilidad es esencial
Esencial vs Detallista

Espacio es esencial
Usabilidad es esencial
El Material de Construcción es un
detalle
La ornamentación es un detalle
 Esencial vs Detallista

El dominio es esencial
Los casos de uso son esenciales
Esencial vs Detallista

El dominio es esencial
Los casos de uso son esenciales
La presentación es un detalle
La persistencia es un detalle
Arquitectura Hexagonal
Arquitectura Onion
Arquitectura Clara o Clean
Todo al mismo tiempo
¿Por qué usar una arquitectura centrada en el dominio?

Pros
Enfocada en el dominio
Bajo acoplamiento
Permite el diseño dirigido por
dominio
¿Por qué usar una arquitectura centrada en el dominio?

Pros Cons

Enfocada en el dominio Cambios son difíciles

Bajo acoplamiento
Requiere más ideas

Permite el diseño dirigido por

dominio Alto costo al inicio
Principios y procesos en la Arquitectura de
Software
Principios y procesos en la
Arquitectura de Software

●Desarrollo iterativo e incremental.

●Conducido por las calidades sistémicas.
●Centrado en la arquitectura.
●Dirigido por los casos de uso.
●Basada en Modelos.
●Mejores prácticas de diseño
Proceso de la Arquitectura de software

Un proceso de arquitectura es una secuencia de actividades

que conllevan a la producción de artefactos (Elementos de
información producidos, modificados o usados por el proceso)
arquitectónicos.

●Fase de Inicio
●Fase de Elaboración
●Fase de Construcción
●Fase de Transición.
Proceso de la Arquitectura de software

Fase de Inicio
Con respecto a la arquitectura, en la fase de inicio de los
proyectos se establece:

○ Requerimientos no-funcionales
○ Lista de riesgos y restricciones
○ Arquitectura inicial
Proceso de la Arquitectura de software

Fase de Elaboración
Con respecto a la arquitectura, en la fase de elaboración
se establece:
Arquitectura línea base.

Entregables:
○ Documento de Definición de Arquitectura.
○ Prototipo evolutivo de arquitectura.
○ Guías y Estándares de Diseño.
Proceso de la Arquitectura de
software
Fase de Construcción

• En esta fase todas las componentes restantes se desarrollan

e incorporan al producto.
• Todo es probado en profundidad.
• El énfasis está en la producción eficiente y no ya en la
creación intelectual.
• Puede hacerse construcción en paralelo, pero esto exige
una planificación detallada y una arquitectura muy estable
Proceso de la Arquitectura de
software

Fase de Transición
• El objetivo es traspasar el software desarrollado a la
comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que
implicarán nuevos desarrollos (ciclos).
• Incluye:
– Pruebas para validar el producto con las expectativas
del cliente
– Ejecución paralela con sistemas antiguos
– Conversión de datos
– Entrenamiento de usuarios
– Distribuir el producto.
Proceso de la Arquitectura de
software
Diagramas UML orientados a la arquitectura de
software
Diagramas UML orientados a la Arquitectura de Software

Objetivos en el diseño de UML

● Modelar sistemas, desde los requisitos hasta los artefactos
ejecutables desplegados en nodos, utilizando técnicas OO.
● Cubrir las cuestiones relacionadas con el tamaño propias de
los sistemas complejos y críticos.
● Lenguaje utilizable por las personas y las máquinas
● Encontrar equilibrio entre expresividad y simplicidad.
Diagramas UML orientados a la Arquitectura de Software

Modelado del Software

● El modelado es el análisis y diseño de aplicaciones software

antes de escribir el código.
● Se crean un conjunto de modelos (“planos del software”)
que permiten especificar aspectos del sistema como los
requisitos, la estructura y el comportamiento.
● Los modelos
○ Ayudan a razonar sobre el sistema
○ favorecen la comunicación
○ permiten documentar las decisiones
○ permiten una generación automática de código
Modelado de casos de uso
Ejemplo
 Diagrama de Casos de uso
Ejemplo:
Modelado de Casos de Uso
 Relaciones de los casos de uso

• Inclusión – utiliza un paso de un caso de uso en otro caso de

uso
– Ejemplo: El caso de uso “Cancelar una Orden” incluye
el caso de uso “Localizar una Orden”

Cancela include
orden Busca Orden
 Relaciones de los casos de uso

● Extensión – crea un nuevo caso de uso añadiéndole pasos

al caso de uso existente. Es una alternativa para el flujo de
eventos
● Representada por una línea de dependencia con el
estereotipo <<extend>>
● Ejemplo: El caso de uso “Colocar una Orden” puede incluir
las etapas del caso de uso “Descuento para Cliente
Frecuente”

<<extend>>
Descuento a
Coloca Orden cliente frecuente
Relaciones de los casos de uso
Modelo de Dominio
 Modelado del Dominio
Modelo de Dominio de un sistema de subterráneo
El siguiente diagrama es un pequeño ejemplo de Modelo de
Dominio, en este caso, referido al Metro o sistema de transporte
subterráneo de una ciudad cualquiera.
Diagrama de Componentes
• Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un conjunto
de interfaces a las que proporciona su realización.

• Los componentes tienen dos características: Empaquetan el código que implementa la funcionalidad de un
sistema, y algunas de sus propias instancias de objetos que constituyen el estado del sistema.

• Los llamados últimos componentes de la identidad, porque sus instancias poseen identidad y estado.

Representación gráfica
 Diagrama de Componentes
• Los artefactos de los que depende su construcción
son:
– Diagrama de objetos
Dependencias
– Diagrama de clases
• Los artefactos que se generan a partir del diagrama
de complementos son:
– Diagrama de ejecución
– Diagrama de despliegue
Diagrama de Componentes
 Diagrama de Componentes
Tipo de diagrama del Lenguaje Unificado de Modelado que se
utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones.
 Diagrama de Despliegue
● Se ocupa de modelar un aspecto de la vista de despliegue
estática de un sistema.
● Contiene sólo aquellos elementos que son esenciales para
comprender ese aspecto.
● Proporciona detalles de forma consistente con el nivel de
abstracción, mostrando sólo aquellos adornos que son
esenciales para su comprensión.
● No es tan minimalista que no ofrezca información al lector
sobre los aspectos importantes de la semántica.
 Diagrama de Despliegue
El Diagrama de Despliegue es muy similar al de componentes
por lo que también comparte la forma de notación que se ve a
continuación:
 Diagrama de Despliegue
Los diagramas de despliegue sirven para modelar la
configuración hardware del sistema, mostrando qué nodos lo
componen
 Diagrama de Despliegue

Diagrama de despliegue de solicitud de búsqueda de

información de pacientes.
 Diagrama de despliegue
Diagrama de despliegue de un caso en general.
Visión de Arquitectura Orientada a
Servicios (SOA)

Requerimientos Arquitectónicos

● Heterogeneidad
● Escalabilidad
● Disponibilidad
● Distribución
● Manejabilidad de Procesos
● Administración y monitoreo de procesos, servicios e
infraestructura
 Conclusiones
• La arquitectura es aplicado como estrategia para enfrentar la
complejidad de los sistemas actuales.
• Las actividades alrededor de la arquitectura deben
integrarse al proceso de desarrollo.
• UML provee facilidades para definición de la arquitectura
• Los casos de uso sólo consideran los requisitos funcionales
del proyecto, hay que añadir los no-funcionales.
• Los casos de uso es una de escribir con el detalle necesario el
flujo principal y los flujos alternativos.
 Gracias
Docente: Alfredo Asmat Ramón