Unidad 4: Modelo
de diseño
La fase de diseño (y los modelos de UML resultantes) expande y detalla
los modelos de análisis tomando en cuenta todas las implicaciones y
restricciones. El propósito del diseño es especificar una solución que trabaje
y pueda fácilmente se convierta en código fuente y construir una arquitectura
simple y fácilmente entendibles. Las clases definidas en el análisis fueron
detalladas y se añaden nuevas clases para manejar áreas técnicas como base de
datos, interfaces del usuario.
4.1
Estrategia de diseño
Abstracción: Para un problema determinado se pueden considerar muchos grados de
abstracción. En un alto grado de abstracción una solución se establece en
términos generales con el lenguaje de entorno del problema en los grados de menor
abstracción. En un alto grado de abstracción una solución se establece en términos generales con
el lenguaje de entorno del problema.
Arquitectura: La arquitectura del software alude a la
estructura general del software y las formas en la que la estructura proporciona
una integridad conceptual para un sistema. La arquitectura es la estructura u
organización de los componentes del programa (módulos), la manera en que estos
componentes interactúan, y la estructura de datos que utilizan los componentes.
Patrones: Un
patrón de diseño describe una estructura de diseño que resuelve un problema
recurrente de diseño particular dentro de un contexto específico y en medio de
fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el
patrón.
Modularidad:
Los patrones de arquitectura y diseño de software materializan la modularidad;
es decir, el software se divide en componentes con nombres independientes y que
es posible abordar en forma individual. Estos componentes llamados módulos se
integran para satisfacer los requisitos del problema. La modularidad se basa en
la estrategia divide y vencerás (es más fácil resolver un problema complejo
cuando éste se divide en piezas más manejables).
Ocultación de
información: Sugiere que los módulos se caracterizan por las
decisiones de diseño que cada uno oculta a los otros. Los módulos deben
especificarse y diseñarse de manera que la información (procedimientos y datos)
que está dentro del módulo sea inaccesible para otros módulos que no necesiten
esta información.
No hay comentarios:
Publicar un comentario