Vous êtes sur la page 1sur 44

Enero 2006 2

Contenido de la sesin
Diseo de Software
Principios del Diseo
Arquitectura de Software
Especificacin de Arquitecturas
Enero 2006 3
Diseo de Software
Es una descripcin de la estructura del software que se va a
implementar, los datos que son parte del sistema, las interfaces
entre los componentes del sistema, y algunas veces, los
algoritmos utilizados.
Los diseadores no obtienen inmediatamente un diseo
detallado, sino que lo desarrollan de manera iterativa a travs
de diversas versiones.
El proceso de diseo incluye agregar formalidad y detalles
durante el desarrollo del diseo, y regresar a los diseos
anteriores y corregirlos.
El Proceso de diseo es an un proceso ad hoc
Enero 2006 4
Servidor de Datos
Servidor de Aplicaciones
PC
Workstation
Otro Sistema
Interfaces Hombre Mquina
Interfaces con otros sistemas
Hardware
Estructura de la Aplicacin
Estructura Base de Datos
Topologa de Red
Diseo de Software
Enero 2006 5
Diseo de Software
El proceso de diseo incluye el desarrollo de varios modelos
con diferentes niveles de abstraccin
Especificacin
De
Requerimientos
Diseo
Arquitectnico
Diseo De
Interfaz
Especificacin
Abstracta
Diseo de
Componentes
Diseo de
Est. De datos
Diseo de
Algoritmos
Arquitectura
Del Sistema
Especificacin
Software
Especificacin
Interfaz
Especificacin
Datos
Especificacin
Algoritmos
La retroalimentacin entre estas actividades y la consecuente
repeticin del trabajo es inevitable en todo proceso de diseo
Especificacin
Componentes
Enero 2006 6
Diseo de Software
1. Diseo de datos: transforma el modelo de dominio de la
informacin, creado durante el anlisis, en las estructuras de
datos necesarias para implementar el software.
2. Diseo arquitectnico: define la relacin entre los
principales elementos estructurales del programa.
3. Diseo de interfaz: describe cmo se comunica el software
consigo mismo, con los sistemas que operan con l y con los
operadores que lo emplean.
4. Diseo procedimental: transforma elementos estructurales
de la arquitectura del programa en una descripcin
procedimental de los componentes de software.
Enero 2006 7
Diseo de Software
RELACIN ENTRE LOS ELEMENTOS DE ANLISIS Y
DISEO
El modelo de anlisis El modelo de diseo
Especificacin del proceso (EP)
Diagrama de transicin de estado
(DTE)
Especificacin de control (EC)
Diseo procedimental
Diagrama de flujo de datos (DFD) Diseo de interfaz
Diagrama de flujo de datos (DFD) Diseo arquitectnico
Diccionario de datos
Diagrama entidad-relacin (E-R)
Diseo de datos
Enero 2006 8
Diseo de Software
Los sistemas grandes siempre se descomponen en subsistemas
que suministran algn conjuntorelacionado de servicios.
El proceso de diseo inicial para identificar estos subsistemas
y establecer un marco de trabajo para el control y
comunicacin de los subsistemas se llama diseo
arquitectnico y lo que produce este proceso de diseo es una
descripcin de la Arquitectura de Software.
La descomposicin arquitectnica es necesaria para estructurar
y organizar la especificacin
Enero 2006 9
Diseo de Software
Resumiendo las razones expuestas por el Software EngineeringInstituteas
como las propuestas por Bass et al. (SEI, 2000) (Bass et al.,2003), se puede
contar con cuatro necesidades fundamentales para considerar importante la
arquitectura del software las cuales justifican su anlisis:
La comunicacin entre los participantes: por representar una abstraccin
de alto nivel de un sistema que la mayora, sino todos, los participantes
pueden usar para crear un entendimiento comn.
Decisiones de diseo tempranas: es tambin el punto ms temprano en
el cual el sistema a ser construido puede ser analizado.
Abstraccin transferible de un sistema: la arquitectura del software
constituye un modelo pequeo e intelectualmente comprensible de
cmo el sistema est estructurado y de cmo colaboran entre s sus
componentes. Este modelo es transferible a otros sistemas,
especialmente a aquellos con requerimientos similares.
La arquitectura del software es el primer artefacto de diseo que
direccionaal menos cuatro atributos de calidad relevantes: desempeo,
confiabilidad, modificabilidad y seguridad.
Enero 2006 10
Principios del Diseo de Software
No debera ponerse orejas (considerar enfoques alternativos).
Se debera poder seguir los pasos del diseo desde el modelo de anlisis.
No debe inventar nada que ya est inventado.
Debera minimizar la distancia intelectual entre el software yel problema
tal y como existe en el mundo real.
Debera presentar uniformidad e integracin.
Debera estructurarse para admitir cambios.
Debera estructurarse para degradarse poco a poco, incluso cuando se
enfrenta a datos, sucesos o condiciones operativas aberrantes.
No es escribir cdigo y escribir cdigo no es disear.
Se debera valorar la calidad del diseo mientras se crea no despus de
terminarlo.
Se debera revisar el diseo para minimizar los errores conceptuales
(semnticos).
Enero 2006 11
Principios del Diseo de Software
ABSTRACCIN
La nocin psicolgica de abstraccin permite concentrarse en
un problema a un nivel de generalizacin independiente de los
detalles de nivel inferior, la abstraccin tambin permite
trabajar con conceptos y trminos que son familiares en el
entorno del problema sin tener que transformarlos en una
estructura poco familiar.
Cada fase del proceso de ingeniera del software es un
refinamiento en el nivel de abstraccin de la solucin software.
Finalmente se alcanza el nivel inferior de abstraccin cuando
se construye el cdigo.
Enero 2006 12
Principios del Diseo de Software
Abstraccin procedimental: es una secuencia dada de
instrucciones que tiene una funcin especfica y limitada.
Abstraccin de datos: es una coleccin determinada de datos
que describen un objeto de datos.
Abstraccin de control: implica un mecanismo de control del
programa sin especificar detalles internos
Enero 2006 13
Principios del Diseo de Software
REFINAMIENTO PASO A PASO
La arquitectura de un programa se desarrolla refinando
sucesivamente niveles de detalle procedimental.
Se desarrolla una jerarqua descomponiendo un enunciado
macroscpico de funcin (una abstraccin procedimental) al
estilo paso a paso hasta que se llega a los enunciados del
lenguaje de programacin.
La abstraccin y el refinamiento son conceptos
complementarios.
Enero 2006 14
Principios del Diseo de Software
MODULARIDAD.
Se divide el software en componentes identificables y tratables
por separado, denominados mdulos, que estn integrados
para satisfacer los requisitos del programa.
La modularidades el atributo del software que permite a un
programa ser manejable intelectualmente. La complejidad
percibida de un problema que combina p y p; es mayor que
la complejidad percibida cuando cada problema se considera
por separado.
Hay un nmero m de mdulos que resultaran en un costo de
desarrollo mnimo, pero no tenemos la sofisticacin necesaria
para predecir m con seguridad.
Enero 2006 15
Principios del Diseo de Software
Meyer define cinco criterios que permiten evaluar un mtodo de diseocon
respecto a su capacidad de definir un sistema modular eficaz:
Capacidad de descomposicin funcional: mecanismo sistemtico de
descomposicin del problema en sub-problemas.
Capacidad de empleo de componentes modulares: ensamblar
componentes de diseo existentes.
Capacidad de comprensin modular: entender un mdulo como una
unidad por s sola.
Continuidad modular: cambios en los mdulos individuales, en vez de
cambios generalizados en el sistema.
Proteccin modular: los efectos se restringen dentro de ese mdulo.
Enero 2006 16
Principios del Diseo de Software
JERARQUIA DE CONTROL (estructura del programa).
Representa la organizacin (a menudo jerrquica) de
componentes del programa (mdulos) e implica una jerarqua
de control
M
a b c
i
e d
h g f
j
k l m
q p o n
r
Grado de salida
Grado de
entrada
Anchura
Profundidad
Enero 2006 17
Principios del Diseo de Software
Profundidad y anchura: proporcionan una indicacin del nmero de niveles
de control y el mbito global de control, respectivamente.
El grado de salida: es una medida del nmero de mdulos que son
controlados directamente por otro mdulo.
Superior.
Subordinado.
Visibilidad: indica el conjunto de componentes de programa que pueden
invocarse o usarse sus datos por un componente dado, incluso cuando esto
se realiza indirectamente.
Conectividad: indica el conjunto de componentes que son invocados
directamente o usados sus datos por un componente determinado.
Enero 2006 18
Principios del Diseo de Software
PARTICIN ESTRUCTURAL.
Particin horizontal: define ramas separadas de la
jerarqua modular para cada funcin principal del
programa. El enfoque ms simple de particin
horizontal define tres particiones: entrada,
procesamiento y salida. Es ms fcil de probar y de
mantener, propaga menos efectos secundarios, el
software es ms fcil de ampliar.
Enero 2006 19
Principios del Diseo de Software
Funcin 1 Funcin 2 Funcin 3
a) Particin horizontal
Enero 2006 20
Principios del Diseo de Software
Particin vertical: o factoring(descomposicin en factores),
sugiere que el control (toma de decisiones) y el trabajo se
distribuyan descendentemente en la arquitectura del programa.
Los mdulos del nivel superior deberan realizar funciones de
control y poco trabajo de procesamiento.
Los mdulos que residen en la parte baja de la arquitectura
deberan ser los trabajadores, realizando todos los trabajos de
entrada, clculo y salida.
Las arquitecturas de particin vertical tienen menos
probabilidad de ser susceptibles a efectos secundarios cuando
se hacen cambios y tendrn por tanto mejor capacidad de
mantenimiento, un factor clave para la calidad.
Enero 2006 21
Principios del Diseo de Software
b) Particin Vertical
Mdulos de
trabajo
Enero 2006 22
Principios del Diseo de Software
PROCEDIMIENTO DEL SOFTWARE.
El procedimiento del software se centra en los
detalles de procesamiento de cada mdulo
individualmente.
El procedimiento debe proporcionar una
especificacin exacta del procesamiento, incluyendo
la secuencia de acontecimientos, puntos exactos de
decisin, operaciones repetitivas e incluso la
organizacin/estructura de los datos.
Enero 2006 23
Principios del Diseo de Software
Enero 2006 24
Principios del Diseo de Software
DISEO MODULAR EFECTIVO.
Los conceptos fundamentales de diseo sirven para
incentivar diseos modulares.
Un diseo modular reduce la complejidad, facilita los
cambios y hace ms fcil la implementacin al
fomentar el desarrollo en paralelo de diferentes partes
de un sistema.
Enero 2006 25
Principios del Diseo de Software
DISEO MODULAR EFECTIVO.
1. INDEPENDENCIA FUNCIONAL.
Se consigue desarrollando mdulos con una funcin nica y una
aversin a excesiva interaccin con otros mdulos. Cada mdulo trate
una sub-funcin especfica de los requisitos y tenga una sencilla interfaz
cuando se vea desde otras partes de la estructura del programa.
Es ms fcil de desarrollar porque la funcin se puede compartir y las
interfaces se simplifican.
Los mdulos independientes son ms fciles de mantener y probar
porque los efectos secundarios causados por la modificacin del
diseo/cdigo estn limitados, la propagacin de errores es reducida y
se pueden usar mdulos reutilizados.
La independencia se mide usando dos criterios cualitativos: cohesin y
acoplamiento. La cohesin es una medida de la fuerza relativa funcional
de un mdulo. El acoplamiento es una medida de la interdependencia
relativa de entre los mdulos.
Enero 2006 26
Principios del Diseo de Software
2. COHESIN.
Es una extensin natural del concepto de ocultamiento de la
informacin. Un mdulo con cohesin realiza una sola
tarea dentro de un procedimiento de software, requiriendo
poca interaccin con los procedimientos que se realizan en
otras partes del programa. Un mdulo con cohesin debera
hacer una sola cosa.
Siempre debemos buscar la cohesin ms alta, aunque la
parte media del espectro es a menudo aceptable.




Disperso De un solo propsito

BAJA ALTA
Coincidente Lgica Temporal Procedimental De comunic. Secuencial Funcional
Enero 2006 27
Principios del Diseo de Software
Coincidencialmente cohesivo: un mdulo que realiza un
conjunto de tareas poco relacionadas las unas con las otras.
Cohesin lgica: realiza tareas relacionadas lgicamente
(produce toda las salidas).
Cohesin temporal: contienen tareas relacionadas por el hecho
de que todas deben hacerse en el mismo intervalo de tiempo.
Cohesin procedimental: cuando los elementos de
procesamiento estn relacionados y deben ejecutarse en un
orden especfico.
Cohesin de comunicacin: todos los elementos de
procesamiento se concentran en un rea de la estructura de
datos.
Enero 2006 28
Principios del Diseo de Software
3. ACOPLAMIENTO.
Es una medida de la interconexin entre los mdulos de la
estructura de un programa. Depende de la complejidad de la
interfaz entre los mdulos, el punto en el que se entra o se
hace referencia al mdulo y qu datos pasan a travs de la
interfaz. Intentamos conseguir el menor nivel posible de
acoplamiento. Las conexiones sencillas entre los mdulos
hacen que el software sea ms fcil de entender y menos
dado al efecto ola.
BAJA ALTA
Sin acop. Dir. Ac. Datos Ac. Marca Ac. Control Ac. Externo Ac. Normal Ac. contenido
Enero 2006 29
Principios del Diseo de Software
Acoplamiento de datos: est subordinado al mdulo a y se accede a l por
medio de una lista convencional de argumentos a travs de la cual se pasan
los datos.
Acoplamiento de marca: cuando en vez de argumentos simples se pasa una
porcin de la estructura de datos se pasa por la interfaz del mdulo.
Acoplamiento de control: se pasa un indicador de control (una variable que
controla las decisiones en el mdulo subordinado).
Acoplamiento externo: cuando los mdulos estn atados a un entorno
externo al software. Por ejemplo, las I/O y los dispositivos.
Acoplamiento comn: varios mdulos hacen referencia a un rea global de
datos.
Acoplamiento de contenido: un mdulo hace uso de datos o de informacin
de control mantenidos dentro de los lmites de otro mdulo. Cuando se
realiza una bifurcacin hacia la mitad de otro mdulo.
Enero 2006 30
Principios del Diseo de Software
Datos
(variables
)

a
d h
b c
i j
g
e
f
Est. de
datos
Ind. De control
rea global de datos
Sin ac.
directo
Enero 2006 31
Actividad Prctica
PIENSE ESCRIBA COMPARTA
1. De manera individual y en 10 minutos, PIENSE y
ESCRIBA la respuesta de lo siguiente:
Cmo se propician los principios de diseo?
2. A nivel grupal y en mximo 5 minutos, COMPARTA lo que
escribi en el paso anterior.
Duracin 15 minutos
Enero 2006 32
Arquitectura de Software
La Arquitectura del Software de un programa o
sistema de Computacin, es la estructura o estructuras
del sistema, la cual comprende componentesde
Software, propiedades externas de esos componentes y
la interaccinentre ellos[Bas el al 2003].
Por otra parte, Clements [SEI, 2001] seala que la
Arquitectura del Software es vagamente definida como
la estructura organizacional de un sistemade Software
que incluye componentes, conexiones, restricciones.
Enero 2006 33
Arquitectura de Software
Se obtiene mediante un proceso de particin que relaciona
los elementos de una solucin de software con partes de un
problema del mundo real definido implcitamente durante el
anlisis de los requisitos. La solucin aparece cuando cada
parte del problema est resuelta mediante uno o ms elementos
de software.
El diseo y la especificacin completa de la estructura de los
sistemas de software, segn Shawy Garlan (1996), se est
transformando en un aspecto de ms importancia que la
escogencia de los algoritmos y las estructuras de datos, en
virtud del tamao y la complejidad de estos es la actualidad
Enero 2006 34
Arquitectura de Software
Disear la arquitectura del software, segn estos
mismos autores, es definir los aspectos estructurales
como una composicin de componentes, las
estructuras globales de control, los protocolos de
comunicacin, la sincronizacin y acceso a los datos,
la asignacin de la funcionalidad a los elementos del
diseo, la composicin de estos elementos, su
distribucin fsica, su escalabilidad y su desempeo.
Enero 2006 35
Arquitectura de Software
Define al sistema en trminos de elementos
computacionales y de las interacciones entre ellos.
La arquitectura muestra la correspondencia entre los
requerimientos de sistemas y los elementos del sistema
construido, proveyendo as una exposicin racional para
las decisiones de diseo.
Enero 2006 36
Arquitectura de Software
ELEMENTOS COMPUTACIONALES. Son entidades tales
como clientes, servidores, bases de datos, filtros y capas de un
sistema jerrquico. Son adems, una parte encapsulada del
sistema de software, donde cada uno tiene una interfaz.
INTERACCIONES. Ocurren entre los elementos a nivel de
diseo, pudiendo ser tan simples como las llamadas a
procedimientos o variables de acceso, o tan complejas y
semnticamente ricas como los protocolos del modelo
cliente/servidor, los protocolos de acceso a las bases de datos.
(Shawy Garlan, 1996).
Enero 2006 37
Arquitectura de Software
RELACIONES. Denotan las conexiones entre los elementos
computacionales y/o componentes.
Una relacin puede ser esttica o dinmica.
Relaciones estticas. Se muestran en el cdigo fuente, ellas
reflejan la colocacin de los componentes dentro de la
arquitectura.
Relaciones dinmicas. Tratan con las conexiones
temporales y las interacciones dinmicas entre los
componentes. Ellas no son fcilmente visibles a partir del
cdigo fuente.
Enero 2006 38
Actividad Prctica
PIENSE ESCRIBA COMPARTA
1. De manera individual y en 10 minutos, PIENSE y
ESCRIBA la respuesta de lo siguiente:
Cul es la diferencia entre Arquitectura de Software y
Diseo de Software?
2. A nivel grupal y en mximo 5 minutos, COMPARTA lo que
escribi en el paso anterior.
Duracin 15 minutos
Enero 2006 39
Representacin de la Arquitectura
En la actualidad el desarrollo de los sistemas se centra en la
arquitectura de software y es especificada utilizando el Modelo
4+1 Vistas de Kruchten (1995).
Vista Lgica
Vista Lgica
Vista de Proceso
Vista de Proceso
Vista de I mplementacin
Vista de I mplementacin
Vista de I mplantacin
Vista de I mplantacin
Casos de Uso
Casos de Uso
Programadores
gerencia del software
Ingenieros de sistemas
topologa del sistema
entregas
instalacin
telecomunicacin
Integradores de sistemas
desempeo
escalabilidad
rendimiento
Usuarios finales
funcionalidad
Enero 2006 40
Representacin de la Arquitectura
VISTA LGICA. Describe el modelo objeto del diseo
cuando un mtodo de diseo O-O es usado;se puede usar un
enfoque alterno para desarrollar alguna otra forma de vista
lgica
VISTA DE PROCESO. Describe los aspectos de diseo
relacionados con la concurrencia y la sincronizacin.
VISTA IMPLANTACIN. Describe el mapa del SW dentro
del HW refleja los aspectos de distribucin.
Enero 2006 41
Representacin de la Arquitectura
VISTA DE IMPLEMENTACIN. Describe la organizacin
esttica del software en el ambiente de desarrollo.
CASOS DE USO. Los diseadores de software organizan la
descripcin de sus decisiones arquitecturales alrededor de estas
cuatro (4) vistas, y las ilustran con una pequea seleccin de
casos de uso o escenarios, constituyendo as la quinta vista. La
arquitectura est parcialmente producida por esos escenarios.
Enero 2006 42
Representacin de la Arquitectura
Lgica
Procesos
Se identifican caractersticas
tales como: Autonoma, quien
invoca a quien.
Persistencia. Distribucin:
desde donde son accesibles
las operaciones.
Lgica
Implementacin
Una clase se puede
implementar en un mdulo,
paquete, etc.
Enero 2006 43
Decisiones Arquitectnicas
Si una propiedad de un elemento arquitectnico no es
visible o no es discernible de cualquier otro elemento
arquitectnico, ese elemento no es arquitectnico.
La seleccin de un manejador de base de datos no es
una decisin arquitectnica. La razn de su existencia
no es materia (no le concierne) a las metas
arquitectnicas.
Las decisiones son arquitectnicas o no de acuerdo al
contexto. Si la estructura es importante para alcanzar
las metas del sistema la estrutura es arquitectnica.
Enero 2006 44
Actividad Prctica
PIENSE ESCRIBA COMPARTA
1. De manera individual y en 10 minutos, PIENSE y
ESCRIBA la respuesta de lo siguiente:
De dos ejemplos de decisiones arquitectnicas
De un ejemplo de una decisin no arquitectnica
2. A nivel grupal y en mximo 5 minutos, COMPARTA lo que
escribi en el paso anterior.
Duracin 15 minutos
Enero 2006 45