Patricio Abad Espinoza

 ¿Qué es el diseño del sistema?

 Es la transformación de un modelo de análisis en un modelo de diseño.
 Los diseñadores definen los objetivos de diseño del proyecto y descomponen el sistema
en sub sistemas capaces de ser desarrollados por equipos individuales.
 Definen además estrategias para construir el sistema:
 Estrategias para consolidar hardware y software
 Manejo de la persistencia de datos
 El flujo de control global
 La política de control de acceso.
 Manejo de condiciones límite.
 Además el diseño incluye una clara descripción de cada una de las estrategias.
 El diseño no es algorítmico.
 Identificar los objetivos de diseño
 Identificar y priorizar las elementos de calidad del sistema para los que debe
optimizarse la aplicación.
 Diseñar la descomposición inicial del sistema.
 Descomponen el sistema en partes más pequeñas basados en casos de uso y el modelo
de análisis.
 Utilizan estilos arquitectónicos estándares como puntos de partida durante esta actividad.

 Refinar la descomposición de subsistemas para acoplarlos a los objetivos de

diseño.
 La descomposición inicial por lo general no satisface todos los objetivos de diseño.
 Los desarrolladores refinan el modelo hasta que se han satisfecho todos los objetivos de
diseño.
 Restricciones
 Debe tener dos habitaciones, un estudio, una cocina y una sala
 Minimizar la distancia global recorrida por los ocupantes de la casa
 Optimizar el uso de la luz del día.

 Supuestos
 La mayor parte del camino se realizará entre la puerta de entrada y la cocina cuando se
descargan los comestibles desde el vehículo, y desde la cocina hacia el comedor cuando
se sirven los platos.
 Otra ruta de camino que debe minimizarse es desde las habitaciones al baño.
 Los ocupantes de la casa pasan la mayor parte del tiempo en la sala/comedor y en el
cuarto máster.
Gradas
Estudio Comedor

Cocina
Puerta de entrada
Hall

Habitación 2 Baño Habitación máster

Gradas
Estudio Habitación 2

Cocina
Puerta de entrada
Hall

Comedor Baño Habitación máster

 Puerta de 
Gradas entrada
Estudio Baño

Habitación 2

Cocina
Hall

Comedor Habitación máster
 Concepto arquitectura Concepto SWE
Componentes Habitaciones Subsistemas
Interfaces Puertas Servicios
Requerimientos no funcionales Área de estar Tiempo de respuesta
Requerimientos funcionales Casa residencial Casos de uso
Costo del retrabajo Mover paredes Cambiar interfaces de
subsistemas
 El modelo de análisis produce:
 Un conjunto de requerimientos no funcionales y restricciones (tiempos máximos de
respuesta, producción mínima, confiabilidad, plataforma de operación, etc.
 Un modelo de casos de uso, que describe las funcionalidad del sistema desde el punto
de vista del actor.
 Un modelo de objetos, que describe las entidades manipuladas por el sistema.
 Un diagrama de secuencia por cada caso de uso, mostrando la secuencia de
interacciones entre objetos participantes en el caso de uso.
 El modelo de análisis describe el sistema completamente desde el punto de vista
de los actores y sirve de base para la comunicación entre clientes y
desarrolladores
 El modelo de análisis no contiene información acerca de la estructura interna del
sistema, su configuración de hardware, o cómo se realizará el sistema.
 Objetivos
Atributos de calidad
de diseño

Subsistemas,
responsabilidades,
dependencias, hardware, Arquitectura
control de acceso, de software
almacenamiento y flujos
de control

Configuración del sistema,

Casos de inicio, apagado, manejo de
uso borde excepciones
 Derivan de los requerimientos no funcionales.
 Guían las decisiones que tomarán los desarrolladores cuando se necesitan ajustes
de compensación.
 La descomposición en subsistemas constituye la parte esencial del sistema.
 Los desarrolladores dividen el sistema en piezas manejables para reducir la
complejidad.
 Cada subsistema se asigna a un equipo y se construye de manera independiente.
 Subsistema
 Es una parte reemplazable del sistema con interfaces bien definidas que encapsulan el
estado y el comportamiento de las clases contenidas.
 Típicamente corresponde al trabajo que un solo desarrollador o un equipo de desarrollo
puede hacer, reduciendo la necesidad de comunicación.
 En caso de sistemas de alta complejidad, se puede aplicar este principio de
descomposición de manera recursiva para obtener sistemas más simples.
 Componente lógico
 Subsistema que no tiene un equivalente explícito en tiempo de corrida. Ej. Componentes
individuales de negocio integrados en una sola capa de lógica de aplicación tiempo de
corrida.
 Componente físico
 Corresponde a un subsistema que tiene un componente explícito en tiempo de corrida.
Ej. Servidor de base de datos.
 Un subsistema se caracteriza por los servicios que ofrece a otros subsistemas.
 Un Servicio es un conjunto de operaciones relacionadas con un propósito común. Ej. Un
servicio de notificación define operaciones para enviar noticias, buscar canales de
comunicación y suscribirse o des suscribirse a un canal.
 Interfaz de subsistema, está conformada por el nombre de la operación, sus
parámetros, sus valores de retorno
 El diseño del sistema se enfoca en definir los servicios provistos por cada subsistema,
esto es enumerar las operaciones, sus parámetros, y su comportamiento de alto nivel.
 El diseño de objetos se enfoca en la Application programmer interface (API), la cual
refina y extiende las interfaces del subsistema, además incluye el tipo de parámetros y
valores de retorno de cada operación.
 Asembly connectors:
 La interfaz provista se muestra como un ícono de bola con su nombre adjunto
 Acoplamiento
 Número de dependencias entre dos subsistemas. Si dos subsistemas son débilmente
acoplados, son relativamente independientes, por tanto las modificaciones en uno de los
subsistemas tendrán mínimo impacto en el otro.
 Si en el caso de la respuesta a la emergencia se
decide almacenar toda la información persistente en
una base de datos relacional.
 Eso nos llevaría a crear un sub sistema adicional
llamado Database.
 Inicialmente, se diseña la interface a la base de
datos, de forma tal que los subsistemas que deseen
almacenar información pueden incluir comandos en
lenguaje nativo de la base de datos
Inconvenientes
- Alto acoplamiento entre el subsistema Database y los 3 subsistemas más, y
cualquier cambio en el subsistema de Database, implicaría que deberían realizarse
cambios en los demás subsistemas.
 Número de dependencias dentro de un subsistema.
 Si un subsistema contiene muchos objetos que están relacionados entre si y
ejecutan tareas similares, su cohesión es alta.
 Si por el contrario el subsistema contiene un número de objetos no relacionados,
su cohesión es baja.
 La alta cohesión es una propiedad deseable en los sistemas.
 En la práctica hay competencia entre la cohesión y el acoplamiento, siempre se
puede incrementar la cohesión descomponiendo un sistema en sub sistemas, pero
esto incrementa el acoplamiento.
 Se recomienda usar la regla 7+- 2 conceptos a cualquier nivel de abstracción.
 Si el sistema se demasiado grande, debe considerar la descomposición en
sistemas más pequeños.
 Una capa es un grupo de subsistemas que proveen un conjunto de servicios
relacionados.
 Las capas se encuentran ordenadas de modo que cada una dependa de una de
nivel inferior y las de nivel inferior no tiene conocimiento de las de nivel
superior.
 La capa que no depende de ninguna otra, se conoce como capa inferior.
 La capa de la cual no depende ninguna otra es la capa superior.
 A partir de estos principios y el crecimiento de las aplicaciones distribuidas, se ha
desarrollado lo que conocemos como Middleware (capa intermedia que permite
el intercambio de información entre capas.
 CORBA y Java RMI permiten acceder a objetos remotos de manera transparente medinate
el envío de mensajes
 SWING es un ejemplo de arquitectura abierta.
 Es el proceso de definir una solución estructurada que cumple todos los
requerimientos técnicos y operacionales, mientras optimiza atributos de calidad
comunes tales como rendimiento, seguridad, manejabilidad.
 Involucra muchas decisiones basadas en un amplio rango de factores.
 Cada una de estas decisiones tiene amplio impacto en la calidad, rendimiento,
manejabilidad y en éxito global de la aplicación.
 Según Krutchen et Al:
 Engloba decisiones significativas sobre la organización de un sistema de software
incluyendo: elementos estructurales y sus interfaces, el comportamiento especificado en
la colaboración entre estos elementos, estilo arquitectónico que guía su organización.
 Involucra: funcionalidad, usabilidad, resiliencia, rendimiento, reutilización,
comprensibilidad, restricciones de tecnología y económicas, soluciones intermedias y
aspectos estéticos.
 El software debe construirse sobre bases sólidas.
 Las herramientas y plataformas, no sustituyen la necesidad de diseñar
cuidadosamente las aplicaciones.
 Los riesgo de una arquitectura pobre: aplicación inestable, dificultades para
soportar requerimientos actuales o futuros de la organización, dificultad para
gestionar o liberarla a un entorno de producción.
 El software debe diseñarse considerando: el usuario, el sistema (infraestructura de
TI), y los objetivos de negocio.

Por cada aspecto se debe considerar:

- Escenarios clave con atributos de calidad.
- Aspectos clave de satisfacción o insatisfacción.
- Donde sea posible desarrollar y considerar
métricas
 Las soluciones intermedias pueden resultar deseables y debe haber un balance
entre requerimientos que compiten.
 Experiencia de usuario con Funciones de Negocio/Infraestructura de TI.
 Rendimiento -> inversiones (100% vs 80%)

 La arquitectura se enfoca en cómo los elementos y componentes dentro de la

aplicación son utilizados por o interactúan con otros elementos y componentes
dentro de la aplicación.
 ¿Cómo se usará la aplicación por parte de los usuarios?
 ¿Cómo será puesta en producción la aplicación y cómo será gestionada?
 ¿Cuáles son los atributos de calidad requeridos para la aplicación, tales como
seguridad, rendimiento, concurrencia, internacionalización, configuración?
 ¿Cómo puede la aplicación diseñarse para ser flexible y mantenible en el tiempo?
 ¿Cuáles son las tendencias arquitectónicas que podría impactar su aplicación
ahora y luego de que que sea liberada?
 Es un puente entre requerimientos de negocio y los requerimientos técnicos.
 Identificar los requerimientos que afectan la estructura de la aplicación.
 La arquitectura debe:
 Mostrar la estructura del sistema, pero ocultar los detalles de implementación.
 Realizar todos los escenarios y casos de uso.
 Direccionar los requerimientos de varios stakeholders
 Manejar tanto requerimientos funcionales como no funcionales.

 Horizonte de la arquitectura
 Empoderamiento del usuario
 Madurez del mercado.
 Diseño flexible
 Tendencias futuras
 Construir para cambiar en lugar de construir para durar.
 Modelar para analizar y reducir riesgos
 Utilice modelos y visualizaciones como herramientas de comunicación y
colaboración.
 Identifique decisiones de ingeniería claves.
La arquitectura de software se
describe con frecuencia como
la organización o la estructura
de un sistema, donde el
sistema es una colección de
componentes que cumplen
una función o un conjunto de
funciones
 Separación de áreas de interés
 Principio de responsabilidad única
 Principio del menor conocimiento
 Eliminar la repetición
 Minimizar el esfuerzo de diseño
 Mantenga los patrones de diseño consistentes dentro de cada capa.
 No duplique la funcionalidad dentro de la aplicación.
 Prefiera la composición a la herencia
 Defina un estilo de codificación y convenciones de nombres para el desarrollo.
 Mantenga la calidad del sistema utilizando técnicas automatizadas de QA durante
el desarrollo.
 Considere la operación de su aplicación.
 Separe áreas de interés
 Sea explícito sobre cuántas capas se comunican con otras.
 Utilice abstracciones para implementar bajo acoplamiento entre capas.
 No mezcle diferentes tipos de componentes en las misma capa lógica.
 Mantenga la información consistente dentro de la capa o componente.
 Mantenga los formatos de datos consistentes dentro de una capa o componente.
 Un componente o u objeto no debe depender de detalles internos de otros
componentes.
 No sobrecargue la funcionalidad de un componente.
 Comprenda como los componentes se comunicarán entre si.
 Mantenga el código transversal abstraído de la lógica de negocio de la aplicación
en la medida de lo posible
 Defina un contrato(interfaz) claro para los componentes.
 Defina el tipo de aplicación
 Determine la estrategia de implantación.
 Determine las tecnologías apropiadas.
 Determine los atributos de calidad.
 Determine aspectos transversales
 Un estilo arquitectónico, a veces llamado patrón arquitectónico, es un conjunto de
principios, que a nivel general proporciona un marco abstracto para una familia de
sistemas.
 Un estilo arquitectónico mejora la partición y promueve la reutilización del diseño
al proporcionar soluciones a problemas frecuentemente recurrentes.
 Puede pensar en estilos de arquitectura y patrones como conjuntos de principios
que dan forma a una aplicación.
 Los subsistemas acceden y modifican una sola estructura de datos denominada
repositorio central.
 Los subsistemas son relativamente independientes e interactúan únicamente a
través del repositorio.
 El flujo de control puede ser dictado tanto por el repositorio central, como por los
subsistemas.
 Se usan típicamente para DBMSs, tale como roles de pagos, o sistemas bancarios.
 La localización central de la información, hace más fácil el trabajo con la
concurrencia y la integridad entre sub sistemas.
 Aplicaciones con procesamiento de datos complejo y sujeto a muchos cambios.
 Una vez definido el repositorio, fácilmente se puede añadir nuevos servicios en
forma de subsistemas adicionales.
 Desventajas
 Una desventaja es que el repositorio puede fácilmente convertirse en un cuello de
botella.
 El acoplamiento entre cada sub sistema y el repositorio es alto, esto hace difícil
que se hagan cambios en el repositorio sin afectar a todos los sub sistemas.
 Los subsistemas se clasifican en tres tipos:
 Modelos: Los subsistemas mantienen el conocimiento del dominio.
 Vista: Los subsistemas muestran información al usuario.
 Controlador: Gestionan la secuencia de interacciones con el usuario

 Los subsistemas de Modelo, se diseñan de forma tal que no dependen de ningún

sub sistema Vista o Controlador.
 Los cambios en el estado de los subsistema de modelo, son propagados al
subsistema Vista a través de u protocolo subscripción/notificación.
 EL MVC es un caso especial de repositorio en el cual Modelo implementa la
estructura de datos central y los objetos control, dirigen el flujo de control.
 El servidor provee servicios a las instancias de otros subsistemas llamados
clientes, las cuales son responsables de interactuar con el usuario.
 La solicitud de un servicio se hace usualmente a través de un mecanismo de
llamada remota o un objeto común.
 El flujo de control en clientes y servidores es independiente, excepto por la
sincronización para administrar las solicitudes o para recibir resultados.
 Un ejemplo de este tipo de sistemas, es u sistema de información con una base de
datos central. El cliente es responsable de recibir entradas del usuario, ejecutando
chequeos de rangos, iniciando transacciones en la base de datos cuando se
recogido toda la información necesaria. El servidor es responsable de ejecutar la
transacción y garantizar la integridad del los datos.
 Es un caso especial de repositorio, en el cual la estructura de datos central es
gestionada por un proceso.
 El estilo cliente servidor, no está restringido a un solo servidor.
 En la WWW, un solo cliente puede fácilmente acceder a datos de miles de
servidores.
 Es una generalización del estilo cliente/servidor, en le cual los subsistemas
pueden actuar como clientes o servidores, en el sentido de que cada subsistema
puede solicitar y proveer servicios.
 El flujo de control entre cada subsistema es independiente de otros, excepto por la
sincronización de solicitudes.
 Organiza los subsistemas en tres capas.
 Una capa de interface, incluye todos los objetos borde, que trabajan con el usuario,
incluyendo ventanas, formas, páginas web, etc.
 La capa de lógica de aplicación, incluye todos los objetos entidad y control, que realizan
el procesamiento, chequeo de reglas, y notificaciones requeridas por la aplicación.
 La capa de almacenamiento, realiza el almacenamiento, recuperación y consultas sobre
objetos persistentes.
 Es un tres capas, en el cual la capa de interface se ha descompuesto en capa
Presentation Client, y Presentation Server
 Los subsistemas procesan información recibida de un conjunto de entradas y
envían los resultados a través de un conjunto de salidas. Los subsistemas son
llamados filtros, y la asociaciones entre ellos son llamadas “tuberías”.
 Cada filtro conoce únicamente el el contenido de el formato de la información
recibida en la tubería de entrada, no los filtros que las producen.
 Cada filtro es ejcutado de forma concurrente, y la sincronización es
complementada a través de tuberías.
 Este estilo es modificable: los filtros puede ser sustituidos por otros y
reconfigurados para conseguir diferentes propósitos.
 Ejemplo de este estilo es el Shell de UNIX
 El diseño del sistema consiste en transformar el modelo de análisis en un modelo
de diseño, que tiene en cuenta los requerimientos no funcionales descritos el
documento de análisis de requerimientos.
 Para esta actividad, se utilizan los diagramas de despliegue, los cuales muestran la
organización física de los nodos en tiempo de corrida.
 Nodo: Recurso computacional.
 Artefacto: Entidad auto contenida que provee servicios. Ejm. Archivos de modelos,
archivos fuente, scripts, archivos ejecutables, tablas de bases de datos, entregables
de desarrollo, documentos, mesnajes.
 Entendemos como información persistente a aquella que permanece aún después
de que el sistema se haya ejecutado, es decir los datos de la empresa o del cliente,
esta información puede almacenarse en diferentes formatos, y en este punto es
necesario decidir dónde y cómo se almacenará la información.
 Pasos
 Identificar objetos persistentes (entidad) y aquellos que podría requerirse que persistan.
 Seleccionar estrategia de almacenamiento:
 Archivos planos
 Bases de datos relacionales
 Bases de datos OO
 Otros
 Es necesario definir qué objetos pueden ser accedidos por los actores y que clase
de acceso pueden tener en función del trabajo que deben realizar con el sistema,
estas decisiones desde luego van relacionadas con los requerimientos de
seguridad identificados
 Los accesos se pueden representar utilizando varias técnicas, como por ejemplo
una tabla “acceso global” una “lista de control de accesos” y una asociación entre
el actor y su capacidad.
 El control de accesos también puede aplicarse a nivel de seguridad de acceso
entre equipos de cómputo.
 Otros mecanismos para restringir accesos son la autenticación.
 Control dirigido por procedimientos (Procedure-driven control). Este tipo de flujo de
control es el comúnmente utilizado en sistemas antiguos, ya que el sistema espera por
una entrada de usuario y se escriben en lenguajes procedimentales, no es muy
conveniente utilizar este mecanismo cuando se trabaja con lenguajes orientados a
objetos.
 Control dirigido por eventos (Event-driven control): En este tipo de flujo de control hay
un bucle principal que espera eventos externos, en cuanto se produce uno, este se
asigna al objeto apropiado para resolverlo de acuerdo a la información que acompaña
al evento. Este mecanismo puede causar complicaciones al momento de
implementarse.
 Hilos (Threads): Son una variación del control dirigido por procedimientos, el sistema
crea un número arbitrario de hilos, cada uno respondiendo a diferentes eventos, las
complicaciones en este tipo de control de flujo pueden darse al momento de depurar
la aplicación, a no ser que se disponga de buenas herramientas.
 Las condiciones límite (boundary), permiten decidir cómo el sistema es levantado,
inicializado, y apagado, y es necesario decidir como responder a las fallas de
operación más importantes tales como: daños en los archivos de datos, o pérdida
de conexión, sin importar si se deben a causas del software o por fallos de energía.
 Configuración, se analiza cada objeto persistente buscando en qué momento se crea o se
destruye, si no hay un lugar donde eso suceda, se crea un caso de uso invocado por el
administrador del sistema.
 Inicio y apagado, por cada componente añadimos un caso de uso de inicio, apagado y
configuración.
 Manejo de excepciones, por cada tipo de falla de un componente, se debe decidir cuál
debería ser la reacción del sistema, se documenta cada decisión con un caso de uso que
extiende los casos de uso relevantes de la fase de requerimientos. Las excepciones en
general pueden ser: Fallas de hardware, cambios en el ambiente de operación o fallas de
software. El manejo de excepciones es el mecanismo por el cual el sistema da
tratamiento a una excepción.
 AnnounceTournamentControl
tournament creation workflow.
sponsorship workflow.
interest group workflow.
 Operación de bajo costo, uso de código open source.
 Alta disponibilidad.
 Escalabilidad en términos de número de jugadores y torneos concurrentes.
 Facilidad para añadir nuevos juegos.
 Documentación para desarrollo de código abierto.
 Manejará dos conjutnos de objetos que deben ser almacenados:
 Objetos creados y accesados por el subsistema de organización del juego:
 Torneo
 Juego
 Encuentro
 Jugador
 Ligas
 Los definidos para cada juego por los desarrolladores.

 Estrategia de almacenamiento:
 Base de datos relacional, utilizando JDBC