Arquitectura y

Diseo
del Software
2
Diseo
Es el punto de partida
para los programadores
Es pasar del qu al
cmo
n Sus tcnicas tienen Sus tcnicas tienen
como objetivo como objetivo
primario la primario la
subdivisin del subdivisin del
sistema en varios sistema en varios
subsistemas subsistemas
() ( ) () ( )
() () () ()
() 2.4 () 2.4

Resultados buscados
La suma de las
complejidades de los
subsistemas debe ser
menor a la complejidad
total original
El desarrollo y el
anlisis pueden ser
hechos por grupos
separados
independientes
IMPORTANCIA IMPORTANCIA
DE LAS DE LAS
CONEXIONES CONEXIONES
Etapas del Diseo Ian Sommerville
u Entendimiento del Problema
Mirar el problema desde distintos ngulos para descubrir los
requerimientos de diseo
u Identificar una o ms soluciones
Evaluar soluciones posibles y elegir la ms apropiada segn la
experiencia del diseador y los recursos disponibles.
u Describir las soluciones como abstracciones
Usar notaciones grficas, formales u otras igualmente descriptivas
para definir las componentes del diseo
u Repetir el proceso para cada abstraccin
identificada hasta que el diseo es expresado en
trminos primitivos.
Niveles de Abstraccin
n El diseo
debe ser suficientemente
abstracto para
confrontarlo con la
especificacin
debe ser suficientemente
concreto para brindar
para brindar toda la
informacin para la
implementacin
() ( ) () () () ( ) () ()
() 2.4 () 2.4
program pepe();
Subsistemas de Subsistemas
n Distintos
niveles de
abstraccin
n influencia en
otras fases( ej.:
leng. de prog)
`
`
`
Especificaciones
Cdigo
Hasta dnde?
n hasta qu detalle llegar?
n reglas empricas de
dudosa validez (ej.:
dimensiones de mdulos)
n mtodos segn la
tipologa de las
aplicaciones
n n NO EXISTE EL MTODO NO EXISTE EL MTODO
`
`
`
Cmo hacemos?
En el diseo se fijan las directivas
para el desarrollo
para una misma especificacin
puede haber varios diseos...
se toman las decisiones de diseo
que caracterizarn el producto final.
Un error en el diseo puede ser muy
costoso de superar o remover en la
implementacin.
Fundamental: que las decisiones de
diseo puedan cambiar
respondiendo a los cambios de
exigencias sin que haya que tirar
todo el diseo ni todo el software ya
producido.
De lo informal a lo formal I. Sommervill
Informal
design
outline
Informal
design
More
formal
design
Finished
design
Fases en el proceso de diseo I. Sommerville
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design acti vities
Design pr oducts
No naturales pero necesarias
Fases del diseo
u Architectural design Identificar sub-sistemas
u Abstract specification Especificar subsistemas
u Interface design Describir interfaces etre sub-
sistemas
u Component design Decomponer subsistemas
en componentes
u Data structure design Disear estructuras de
datos para mantener los datos del problema
u Algorithm design Disear los algoritmos para las
funciones del problema
El uso de Diagramas en Diseo
n Diagramas son
fundamentales para
pensar
resolver problemas
comunicacin
n Son la forma
primaria de
representacin
n El trabajo del
diseador es producir
dibujos de trabajo
conjunto de borradores
que dicen que debe
hacerseExploracin de
ideas y soluciones...
n Exploracin de ideas y
soluciones...
Obvia analoga: construir casas
n Para el cliente hay una sola perspectiva
n El arquitecto debe
construir un modelo a escala
hacer diagramas desde distintas perspectivas
Sin mucho detalle pero comprensibles al cliente
n Se necesitan diagramas detallados y especializados
para los gremios
Y CONSISTENTES ENTRE ELLOS
n El rol del arquitecto es crear los aspectos ms
significativos del diseo global
experto en integracin de cada parte pero no experto en
cada una en particular
los diagramas del arquitectos son vistas de los otros
diagramas
De la especific. a la arquitectura
n La arquitectura de
un sistema es
la visin comn de
todos los
trabajadores
(desarrolladores y
actores)
modela los
elementos ms
importantes
n cules? Los que
guan el desarrollo...
Subsistemas
dependencias
interfaces
colaboraciones
nodos
mdulos
Proceso de escritura Proceso de lectura Proceso de clculo
Proceso de control
La arquitectura de software de un sistema es la
estructura o estructuras del sistema que
contiene los componentes soft., las
propiedades visibles externamente y las
relaciones entre ellos.
n Define componentes
n Puede incluir ms de una estructura
n Todo sistema tiene una arquitectura
n Incluye el comportamiento de cada componente
Arquitectura del software
n Presenta las principales decisiones sobre:
organizacin del sistema
elementos estructurales e interfaces que
componen el sistema
su comportamientos definido en las
colaboraciones
la composicin de elementos estructurales y de
comportamiento en subsistemas ms grandes
el estilo arquitectnico que gua la organizacin
Adems se refiere a uso, funcionalidad,
performance, reuso, comprensibilidad,esttica, y
limitaciones tecnolgicas o econmicas.
Para qu una arquitectura?
n Entender el sistema y
comunicacin
n Organizar el desarrollo
n Incrementar el reuso
n Evolucionar el sistema
n Decisiones tempranas
de diseo
n Algunos principios
modularidad
funcional (cohesin)
separar el diseo de
las interfaces del
diseo del servicio
(diseo para el
cambio)
Bajo acoplamiento.
Ingeniera del Software I
Influencias en el arquitecto
Bajo Costo!
Mantener
Empleo
CEO
Cosas Bellas!
Time-to-market
bajo costo
competencia
Marketing
Comportamiento!
Performance
seguridad
confiabilidad!
Usuario
Modificabilidad!
Mantenimiento
Bajo costo,
entrega en tiempo
pocos upgrades!
Cliente
Arquitecto
Se necesita
n creatividad
n conocimiento
n anticipar al cambio
n inventiva
n experiencia
n Seguir principios
Vista funcional de un compilador
Analyse
Build
symbol
table
Scan
source
Generate
code
Symbol
table
Output
errors
urce
gram
Tokens Tokens
Syntax
tree
Object
code
Error
indicator
Symbols Symbols
Error
messages
Vista OO de un compilador
Source
program
Token
stream
Symbol
table
Syntax
tree
Gr ammar
Err or
messages
Abstract
code
Object
code
Scan
Add
Check
Get
Build Print
Generate
Generate
Estructuras Arquitecturales
Estructura Unidad Relacin/Link Util para
Modular Asignacin de
trabajo
Es-submdulo-
de, comparte-
secretos-con
Alocacin de
recursos,
planeamiento,
information
hiding, encap-
sulamiento, conf.
Control
Conceptual Funciones Comparte-datos-
con
Problemas de
espacio
Procesos Programas Corre-paralelo-
con; puede-
correr-paralelo-
con, exclusin,
inclusin
Anlisis de
scheduling y de
performance
Fsico Hardware Requiere la
presencia de
Perfomance,
seguridad
Usa Programas Requiere la
correcta
presencia de
Ingenieril
Llamados Programas Invocacin Performance,
cuellos de botella
Flujo de datos Tasks
funcionales
Puede-enviar-
datos-a
Requerimientos
funcionales
Flujo de control Estados o modos
del sistema
Transiciones Verificacin
Clases Objetos Es una instancia
de, comparte
mtodos de
acceso
Implementacin
Information Hiding
Es el principio fundamental para
que los cambios en el diseo no
perjudiquen todo el proyecto.
Objetivos del Diseo
n Producir el software con
las caractersticas de
calidad que estuvieron
detalladas en la fase de
anlisis y especificacin
de requisitos
n Capacidad de enfrentar
las modificaciones sin
que se ponga en
discusin la aplicacin
ya desarrollada.
Design For Change Design For Change
Objetivos: calidades particulares
Confiabilidad
Modificabilidad
Cambios en el sistema de
clculo
Evolucin en el tiempo de la
especificacin de requisitos
Cambios en el software para
mejorar las prestaciones
Especificacin de requisitos que
resultan inadecuados
Evolucin del mercado
Objetivos: calidades particulares
n Comprensibilidad
n Reusabilidad
Disponer de un conjunto
de componentes
elementales de alto nivel
para componer y generar
las aplicaciones ms
cmodamente
comprar o hacer?
Problema: saber si una
componente sirve.
Criterios Generales
n No existe el mtodo ni el criterio
general
n Hay indicadores
n Uso de varias tcnicas
Formalidad vs. facilidad de instrumentos
n n Divisin en mdulos para reducir la Divisin en mdulos para reducir la
complejidad y prevenir cambios complejidad y prevenir cambios
Recomendaciones de proceso
n Resultado de un arquitecto slo o de un grupo
claramente liderado
n Contar con requerimientos tcnicos y lista priorizada de
calidades.
n Bien documentada y comprensible a todos los actores
(involucrarlos en la revisin)
n Analizada preventivamente por mtricas cuantitativas
(throughput) y cualitativas (modificabilidad)
n Debe considerarse todos los aspectos de contexto y
darse lineamientos para no afectarlos.
Recomendaciones de estructura
Mdulos bien definidos
Responsabilidades divididas segn information hiding y
separation of concerns
Separation of concerns debe permitir dividir el trabajo
en grupos independientes
Information hiding debe ocultar tambin los aspectos
particulares de infraestructura
No debe depender de un producto comercial
Mdulos que producen datos deben ser separados de
los que consumen
Pocos y simples patrones de interaccin
Pasos hacia la arquitectura
Un estilo arquitectnico es una descripcin
de los tipos de componentes y un patrn del
control de runtime y la transferencia de datos
Un modelo de referencia es una divisin de
funcionalidades con el flujo de datos entre las
partes
Una arquitectura de referencia es un modelo
de referencia mapeado en componentes soft.
y el flujo de datos entre ellos.