Contenido de la sesin

Diseo de Software
Principios del Diseo
Arquitectura de Software
Especificacin de Arquitecturas

Enero 2006

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

Diseo de Software
PC
Workstation
Servidor de Aplicaciones

Servidor de Datos
Interfaces Hombre Mquina
Interfaces con otros sistemas
Hardware
Estructura de la Aplicacin
Estructura Base de Datos
Topologa de Red
Enero 2006

Otro Sistema

Diseo de Software

El proceso de diseo incluye el desarrollo de varios modelos

con diferentes niveles de abstraccin

Especificacin
De
Requerimientos

Diseo
Arquitectnico

Arquitectura
Del Sistema

Especificacin
Abstracta

Especificacin
Software

Diseo De
Interfaz

Especificacin
Interfaz

Diseo de
Componentes

Especificacin
Componentes

Diseo de
Est. De datos

Especificacin
Datos

Diseo de
Algoritmos

Especificacin
Algoritmos

La retroalimentacin entre estas actividades y la consecuente

repeticin del trabajo es inevitable en todo proceso de diseo

Enero 2006

Diseo de Software
1.

2.

3.

4.

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.
Diseo arquitectnico: define la relacin entre los
principales elementos estructurales del programa.
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.
Diseo procedimental: transforma elementos estructurales
de la arquitectura del programa en una descripcin
procedimental de los componentes de software.

Enero 2006

Diseo de Software
RELACIN ENTRE LOS ELEMENTOS DE ANLISIS Y
DISEO
El modelo de anlisis

El modelo de diseo

Diseo procedimental
Especificacin del proceso (EP)
Diagrama de transicin de estado
(DTE)
Especificacin de control (EC)

Enero 2006

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

Diseo de Software

Los sistemas grandes siempre se descomponen en subsistemas

que suministran algn conjunto relacionado 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

Diseo de Software

Resumiendo las razones expuestas por el Software Engineering Institute as

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
direcciona al menos cuatro atributos de calidad relevantes: desempeo,
confiabilidad, modificabilidad y seguridad.

Enero 2006

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 y el 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

10

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

11

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

12

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

13

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 modularidad es 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

14

Principios del Diseo de Software

Meyer define cinco criterios que permiten evaluar un mtodo de diseo con
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

15

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

Profundidad

Grado de salida
c

q
Grado de
entrada

Anchura
Enero 2006

16

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

17

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

18

Principios del Diseo de Software

a) Particin horizontal

Funcin 1

Enero 2006

Funcin 2

Funcin 3

19

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

20

Principios del Diseo de Software

b) Particin Vertical

Mdulos de
trabajo

Enero 2006

21

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

22

Principios del Diseo de Software

Enero 2006

23

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

24

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

25

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.
Coincidente Lgica

BAJA
Disperso

Enero 2006

Temporal

Procedimental

De comunic.

Secuencial

Funcional

ALTA
De un solo propsito

26

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

27

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.
Sin acop. D ir. A c. D atos A c. M arca A c. C ontrol

B A JA

Enero 2006

A c. Extern o A c. N orm al A c. con ten ido

ALTA

28

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

29

Principios del Diseo de Software

Sin ac.
directo
a
Est. de
datos

d
Datos
(variables
)

h
Ind. De control

rea global de datos

Enero 2006

30

Actividad Prctica
PIENSE ESCRIBA COMPARTA
1.

De manera individual y en 10 minutos, PIENSE

ESCRIBA la respuesta de lo siguiente:

Duracin 15 minutos

Cmo se propician los principios de diseo?

2.

A nivel grupal y en mximo 5 minutos, COMPARTA lo que

escribi en el paso anterior.

Enero 2006

31

Arquitectura de Software
La

Arquitectura del Software de un programa o

sistema de Computacin, es la estructura o estructuras
del sistema, la cual comprende componentes de
Software, propiedades externas de esos componentes y
la interaccin entre 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 sistema de Software
que incluye componentes, conexiones, restricciones.

Enero 2006

32

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 Shaw y 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

33

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

34

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

35

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.
(Shaw y Garlan, 1996).

Enero 2006

36

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

37

Actividad Prctica
PIENSE ESCRIBA COMPARTA
1.

De manera individual y en 10 minutos, PIENSE

ESCRIBA la respuesta de lo siguiente:

Duracin 15 minutos

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.

Enero 2006

38

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).
Usuarios finales
funcionalidad

Programadores
gerencia del software

VistaLgica
Lgica
Vista

Vistade
deImplementacin
Implementacin
Vista
Casosde
deUso
Uso
Casos

Vistade
deProceso
Proceso
Vista
Integradores de sistemas
desempeo
escalabilidad
rendimiento

Enero 2006

Vistade
deImplantacin
Implantacin
Vista
Ingenieros de sistemas
topologa del sistema
entregas
instalacin
telecomunicacin

39

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

40

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

41

Representacin de la Arquitectura

Lgica

Lgica

Enero 2006

Procesos

Se identifican caractersticas
tales como: Autonoma, quien
invoca a quien.
Persistencia. Distribucin:
desde donde son accesibles
las operaciones.

Implementacin Una

clase se puede
implementar en un mdulo,
paquete, etc.
42

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

43

Actividad Prctica
PIENSE ESCRIBA COMPARTA
1.

De manera individual y en 10 minutos, PIENSE

ESCRIBA la respuesta de lo siguiente:

Duracin 15 minutos

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.

Enero 2006

44

Enero 2006

45