El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces.

Sus ventajas:
Claridad, reduccin de costos y reutilizacin
Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficiente
validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad

a) Independencia funcional
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las
relaciones entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin
b) Acoplamiento
El acoplamiento es un medida de la interconexin entre mdulos en la estructura del programa. Podemos graduarla
en un amplio espectro, pero por lo general se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las
interconexiones entre los distintos mdulos en que se estructure nuestra aplicacin.
c) Cohesin
Un mdulo coherente ejecuta una tarea sencilla en un procedimiento y requiere poca interaccin con procedimientos
que se ejecutan en otras partes de un programa. podemos decir que un mdulo coherente es aquel que intenta
realizar solamente una cosa.
d) Comprensibilidad
se utiliza para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos y es necesario que cada uno sea
comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable que:
- la identificacin y el nombre debe ser adecuado as como descriptivo.
-la Documentacin, debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el
propio cdigo.
- SIMPLICIDAD, las soluciones sencillas son siempre las mejores
e) Adaptabilidad
La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional, es decir, con alto
acoplamiento y baja cohesin, y cuando el diseo es poco comprensible.
los factores para facilitar la adaptabilidad son :
-Previsin: es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro,
de manera que su modificacin afecte al menor nmero de mdulos posibles
-Accesibilidad: debe resultar sencillo el acceso a los documentos de especificacin, diseo, e
implementacin para obtener un conocimiento suficiente del sistema
- Consistencia: , despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos
los documentos afectados
Arquitectura de software
Definicin:
Conjunto de elementos arquitectnicos que tiene una determinada forma (Perry y Wolf).
la Arquitectura de Software se refiere a las estructuras de un sistema, compuestas de elementos con
propiedades visibles de forma externa y las relaciones que existen entre ellos.
Por qu es importante la arquitectura de software?

Es importante ya que debido a la manera en que se estructura un sistema, tiene un impacto directo
sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema


PATRONES DE DISEO
Definicin de patrn SEGN RAE:
UN PATRON ES MODELO QUE SIRVE DE MUESTRA PARA SACAR OTRA COSA IGUAL

Definicin de patrn de diseo:
Christopher Alexander define un patrn de diseo como Una descripcin detallada de una solucin a un problema
recurrente dentro del contexto de un edificio.
Elementos de un patrn
Nombre: describe el problema de diseo.
El problema: describe cundo aplicar el patrn.
La solucin: describe los elementos que componen el diseo, sus relaciones, responsabilidades y colaboracin.
Clasificacin de los patrones
De creacin: conciernen al proceso de creacin de objetos.
De estructura: tratan la composicin de clases y/o objetos.
De comportamiento: caracterizan las formas en las que interactan y reparten
responsabilidades las distintas clases u objetos.



Patrn bridge
Definicin. Es una tcnica usada en programacin para desacoplar la interface de una clase
de su implementacin, de manera que ambas puedan ser modificadas independientemente sin
necesidad de alterar por ello la otra. Este patrn permite modificar las implementaciones de una
abstraccin en tiempo de ejecucin.



A continuacin de describen los participantes de esta estructura

Abstraction: define una interface abstracta. Mantiene una referencia a un objeto de tipo
Implementor.

RefinedAbstraction: extiende la interface definida por Abstraction

Implementor: define la interface para la implementacin de clases. Esta interface no se tiene que
corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser
bastante diferentes entre s. Tpicamente la interface Implementor provee slo operaciones
primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas.

ImplementadorConcreto: implementa la interface de Implementor y define su implementacin
concreta.
Abstraction emite los pedidos de los clientes a su objeto Implementor. El cliente no tiene que
conocer los detalles de la implementacin.


Patrn Factory
Definicin. Es aquel patrn que provee una interface para crear una familia de
objetos similares o independientes sin especificar sus clases concretas.

Ejemplo
Teniendo en cuenta la siguiente jerarqua de clases, la cual trata de representar muy por
arriba dos familias de productos (DVD y BluRay) cada uno con un par de variantes (simple y
doble capa) para que permiten mostrar diferentes aspectos a tener en cuenta a la hora de usar
este patrn.


BUILDER
DEFINICIN. Es un patrn que consiste en hacer una separacin de la construccin de objetos
complejos o compuestos de su representacin de modo que el mismo proceso de construccin
pueda crear diferentes representaciones.



Ejemplo
Este patrn es usado por cadenas de Fast Food para hacer la comida de los nios. Dicha comida consiste
tpicamente en un tem principal, una guarnicin, una bebida y un juguete (Ej. Hamburguesa, papas fritas, una
gaseosa y un dinosaurio de juguete).

Patrn iterator
Definicin. Es la manipulacin de datos mediante los indices de una estructura ya sea esttica
(Arrays) o dinmica (Listas). la condicin de este patrn es que el acceso debe de ser secuencial
mente, a continuacin se mencionan algunas de las operaciones que puede contener una clase
iterador:

-Recorridos uno a uno hacia delante.
-Recorridos uno a uno hacia atras.
-Recorridos en saltos.
-Aplicacin de Filtros.
-Aplicacin de operaciones.
-Consulta de un dato por su posicin.
-etc..
Aqu se muestra una estructura de patrn de diseo

Patrn command
Definicin El patrn de diseo software de comportamiento Command permite realizar una
operacin sobre un objeto sin conocer realmente las instrucciones de esta operacin ni el
receptor real de la misma. Esto se consigue encapsulando la peticin como si fuera un objeto,
con lo que adems se facilita la parametrizacin de los mtodos.
Aqu se muestra la estructura de este patrn de diseo

Patrn estrategia
Definicin es un patrn de diseo para el desarrollo de software, este se clasifica como
patrn de comportamiento porque determina como se debe realizar el intercambio de
mensajes entre diferentes objetos para resolver una tarea, permite mantener un conjunto de
algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene e
intercambiarlo dinmicamente segn sus necesidades.


Patrn decorator
Definicin Este patrn de diseo es aquel que permite modificar, retirar o agregar
responsabilidades a un objeto dinmicamente. Cuando digo dinmicamente, me refiero a que
las funcionalidades se modifican/agregan/retiran durante la ejecucin del script o aplicacin.
Aqu se muestra la estructura de patrn de diseo

Patrn Flyweight
Definicin El patrn Flyweight tambin llamado como objeto ligero, sirve para eliminar o
reducir la redundancia cuando tenemos gran cantidad de objetos que contienen informacin
idntica, adems de lograr un equilibrio entre flexibilidad y rendimiento (uso de recursos).
Aqu se muestra la estructura de este patrn de diseo

Patrn chain of responsibility
Definicin. Es un patrn de comportamiento que evita acoplar el emisor de una peticin a
su receptor dando a ms de un objeto la posibilidad de responder a una peticin. Para ello, se
encadenan los receptores y pasa la peticin a travs de la cadena hasta que es procesada por
algn objeto. Este patrn es utilizado a menudo en el contexto de las interfaces grficas de
usuario donde un objeto puede contener varios objetos. Segn si el ambiente de ventanas
genera eventos, los objetos los manejan o los pasan.

Aqu se muestra la estructura del patrn de diseo


Y a continuacion se mencionan los participantes:
Manejador: define una interfaz para tratar las peticiones. Opcionalmente, implementa el
enlace al sucesor.
ManejadorConcreto: trata las peticiones de las que es responsable; si el
ManejadorConcreto puede manejar la peticin, lo hace; en caso contrario la reenva a su
sucesor.
Cliente: inicializa la peticin a un Manejador Concreto de la cadena.

Patrn de diseo proxy
definicion. Es un patrn estructural que tiene como propsito proporcionar un subrogado o
intermediario de un objeto para controlar su acceso. Este patrn es ampliamente utilizado en
frameworks cmo Hibernate o Spring AOP, permitiendo capturar las llamadas a objetos POJO
y permitiendo insertar en ellas capacidades de persistencia para el caso de Hibernate, u otro
tipo de aspectos como gestin de seguridad o transacciones para Spring AOP.
Aqu se muestra la estructura de este patrn de diseo

Patrn interprete.
Definicin.

Y a continuacion se mencionan y se describen a los participantes:





Ejemplo




Aplicacin del patrn en la vida real.