El documento describe los conceptos de diseño y arquitectura de software. Explica que el diseño conceptual describe qué hará el sistema para el cliente mientras que el diseño técnico explica cómo lo hará para los desarrolladores. También discute los stakeholders del diseñador como el analista, desarrolladores e implementadores, y los factores de calidad como satisfacer requisitos, ser administrable y construible. Finalmente, presenta algunos tipos comunes de arquitectura de software como de una, dos, tres y cuatro capas.

1. 1
Diseño y Arquitectura de
Software
INF302: Introducción a la Ingeniería de Software
Gonzalo Valdés
Departamento de Informática
Universidad Técnica Federico Santa María
gvaldes at inf.utfsm.cl

2. 2
Contenidos
zDiseño
{Conceptual, Técnico
zArquitectura
zAudiencia y Misión del Diseñador
zCalidad del Diseño
zAlgunos tipos de arquitectura

3. 3
Diseño
z Diseño
{Proceso creativo de derivar una solución a partir de un
problema
{La descripción de la solución también se denomina
“Diseño”
z Una característica:
{En general, no hay UNA solución
{En general, no hay una solución “mejor”
{Evaluación y elección depende del cliente
z Punto de partida
{Especificación de requerimientos

4. 4
Proceso de diseño
z Hay dos tareas principales …
{Diseño conceptual (lógico, alto nivel, preliminar)
zExplicar al cliente/usuario QUÉ hará el sistema
{Diseño técnico (físico, bajo nivel, detallado)
zExplicar a los constructores CÓMO lo hará
zDocumento más detallado
z … que deben iterar
{diseño conceptual
{diseño técnico
{refinar diseño conceptual
{refinar diseño técnico
{etc.

5. 5
RUP - “Rational Unified Process”

6. 6
Proceso de diseño
z Documentos (especificaciones de diseño)
{Pueden ser 2 documentos separados
z Ambos documentos explican el MISMO sistema
{Pero de diferente manera
{Con audiencias diferentes
z Analogía: como construir casas
{Clientes reciben maquetas y perspectivas
{Constructores reciben planos eléctricos, sanitarios,
cortes …

7. 7
Proceso de diseño
z Diseño conceptual
{ Escrito en el lenguaje del cliente/usuario
{ No contiene jerga técnica
{ Describe las funciones del sistema
{ Es independiente de la implantación
{ Está vinculado a los documentos de requerimientos
(“trazabilidad”)
z Diseño técnico
{ Componentes de hardware y sus funciones
{ Componentes de software: jerarquía y funciones
{ Estructuras y flujo de datos
z ¿En qué caso conviene hacer un solo documento?
{Depende de los conocimientos del cliente

8. 8
Diseño conceptual
z Describir aspectos fundamentales del sistema
{Ámbito (límites)
{Entidades
{Atributos
{Relaciones
z Responder preguntas como:
{¿De dónde vienen los datos?
{¿Qué le pasa a los datos en el sistema?
{¿Cómo verán los usuarios el sistema?
{¿Qué operaciones y opciones tendrán los
usuarios?

9. 9
Ejemplo - Diferencias entre los Diseños
z El diseño conceptual le
dice al cliente que los
mensajes serán
enrutados de una
ubicación a otra (el
Qué de la solución)
z El diseño técnico le
dice a los
desarrolladores cuál
será el protocolo de
comunicación y la
topología de la red (el
Cómo de la solución)

10. 10
Arquitectura y Diseño
z “Arquitectura de Software”
{ Diseño en grande
{ En general, al construir grandes sistemas es más difícil
cumplir propiedades sistémicas que las funcionales
z Arquitectura/diseño: contraste escala/propósito
{ Análisis dice qué debe hacer el sistema
{ Arquitectura dice qué software hacer (reusar/comprar)
{ Diseño dice cómo hacer el software
z Ojo: arquitectura y diseño son tareas
{ Roles (no excluyentes) de especialistas
{ No hay un límite duro entre ambas cosas

11. 11
Diseñador - Misión
z Tarea del diseñador
{Con una descripción de tareas y propiedades
sistémicas …
{… especificar una solución en términos de
componentes
{… que responda las preguntas de los ‘stakeholders’
z... permitir evaluar a priori el sistema a ser construido
z... ser ‘guía de acción’ a los constructores
z... permitir elaborar un plan de construcción
z Propósito:
{Permitir razonar sobre el sistema y sobre el
proceso

12. 12
Diseñador - Misión adicional
zSupervisar el proceso de construcción
{(usualmente, pero no se requiere)
{Ser ‘guardián de la visión’

13. 13
Audiencia del diseñador
z¿A quién le importa lo que el diseñador
hace?
{‘Stakeholders’
{Implicados; ‘los que tienen algo en juego’
zLos ‘afectados’ por la calidad de lo que hace el
arquitecto
zStakeholders usuales
{Analista (representa al cliente)
{Implantador (programador y/o diseñador de
sub-partes)

14. 14
Stakeholders (simple)
diseñador
specs
constructor
analista
a
r
q
u
i
t
e
t
u
r
a

15. 15
Audiencia del diseñador
zStakeholders usuales
{Analista (representa al cliente)
{Implantador (programador y/o diseñador de
sub-partes)
zStakeholders adicionales
{Jefe de proyecto
{QA (Quality Assurance) y/o integradores
{Administrador del sistema
{Diseñador revisor y/o de otros sistemas

16. 16
Stakeholders
diseñador
revisor
specs
sistem
a
constructor
arquitetura
prueba
analista
a
r
q
u
i
t
e
t
u
r
a
admin
sistem
a
a
r
q
u
i
t
e
t
u
r
a
jefe de
projeto

17. 17
Dualidad proceso/producto
zEl diseñador debe ...
{Describir un sistema a ser construido
{Permitir derivar un proceso para construirlo
{Permitir razonar sobre estos 2 aspectos
zUna arquitectura debe ser más que una
lista de productos
{Y más que un mero modelo de componentes (!)

18. 18
Calidad según los stakeholders
zLa solución (computaciones) debe...
{Satisfacer los requisitos (según analistas)
zLa solución (ejecutables) debe...
{Ser administrable (según administradores)
zLa solución (software) debe …
{Ser ‘construible’ (según programadores &
diseñadores)
{Ser ‘testeable’ (según QA)

19. 19
Calidad según los stakeholders
z La descripción de la solución debe ...
{Ser evaluable (según otros arquitectos), debe
permitir evaluar compromisos y opciones =>
debe haber trazabilidad entre las partes de la
solución y del problema
zEl proceso de construcción debe...
{Ser manejable (según jefe de proyecto)
{Debe ser particionado e indicar dependencias
zParticiones: unidades de asignación de trabajo
zDependencias: la base para definir el calendario

20. 20
Algunos tipos de Arquitectura
z 1 capa: “monolítico”
{ Presentación, negocio, y datos en una sola aplicación en una sola
plataforma. P. ej. Procesador de texto
z 2 capas: “cliente-servidor”
{ Razón: concentrar recursos escasos en servidores centralizados
{ Redundancia mínima
{ Rendimiento puede sufrir

21. 21
3 capas
z Razón: compartir datos, preservando integridad (ACID)
z “Presentación”: interacción con usuarios
z “Negocio” (aplicación): procesos y entidades del negocio
z “Datos”: manejo de datos persistentes

22. 22
4 capas
z “Presentación”: mecanismos de interacción con usuarios
z “Sesión”: manejo de sesiones y transacciones
z “Negocio” (aplicación): procesos y entidades del negocio
z “Datos”: manejo de datos persistentes

23. 23
Referencias
z Base
{Pfleeger 2005 (Chapter 5: Designing the System)
z Pfleeger S. L., & Atlee J. M. Software Engineering: Theory
and Practice, 3rd ed. Prentice Hall, 2005.