4.1 Estrategias de diseño:
A través de la historia de la
ingeniería de software ha evolucionado un conjunto de conceptos fundamentales
de diseño de software. Cada uno ofrece al ingeniero de software un fundamento
sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos
fundamentales del diseño de software ofrecen el marco de trabajo necesario para
hacer las cosas del “modo correcto”.
4.1 Estrategias 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 se proporciona una solución
más detallada de la solución. Una abstracción procedimental
se refiere a una secuencia de instrucciones que tiene una
función específica y limitada.
Una abstracción de datos es una colección nombrada de
datos que describe un objeto de datos. Por ejemplo, se
puede decir que la abstracción procedimental abrir
emplearía la información contenida en los atributos de la
abstracción de datos puerta.
4.1 Estrategias de diseño – Arquitectura
La arquitectura del software alude a la estructura general del
software y las formas en las 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.
4.1 Estrategias de diseño – 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.
4.1 Estrategias de diseño – 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).
4.1 Estrategias de diseño – Ocultación de información
El principio de 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.
4.1 Estrategias de diseño – Independencia funcional
Es la suma de directa de la modularidad y de los conceptos
de abstracción y ocultación de información. La
independencia funcional se consigue al desarrollar módulos
con una función determinante y una aversión a la interacción
excesiva con otros módulos. Los módulos independientes
son más fáciles de mantener, probar, modificar y se reduce
la propagación de errores.
4.1 Estrategias de diseño – Refinamiento
El refinamiento es una estrategia de diseño descendente. El
desarrollo de un programa se realiza al refinar de manera
sucesiva los niveles de detalle procedimentales. El
refinamiento hace que el diseñador trabaje sobre el
enunciado original y que proporcione más y más detalles
conforme se realiza cada refinamiento sucesivo. La
abstracción y el refinamiento son conceptos
complementarios.
4.1 Estrategias de diseño
La meta del diseño es crear un
modelo de software que
implemente todos los requisitos
del cliente de manera correcta y
complazca a aquéllos que lo
usen. El proceso de diseño
avanza de una visión general del
software a una visión más
estrecha que define el detalle
requerido para implementar un
sistema.
El proceso de diseño comienza con
un enfoque en la arquitectura. Se
definen los subsistemas, se
establecen mecanismos de
comunicación entre los subsistemas;
se identifican los componentes y se
realiza una descripción detallada de
cada componente. Además, se
diseñan las interfaces internas,
externas y del usuario.
4.2 Diseño de objetos
Un sistema orientado a objetos está
compuesto de objetos que
interactúan, los cuales mantienen
ellos mismos su estado local y
proveen operaciones sobre su
estado. La representación del estado
es privada y no se puede acceder a
ella directamente desde fuera del
objeto. El proceso de diseño de
objetos comprende el diseño de
clases de objetos y las relaciones
entre estas clases. El diseño
orientado a objetos comprende el
desarrollo de un modelo orientado a
objetos de un sistema de software
para implementar los requerimientos
identificados. Los objetos en un
diseño orientado a objetos están
relacionados con el problema a
resolver.
Un proceso general para el diseño
orientado a objetos puede contener las
siguientes etapas:
•Comprender y definir el contexto y los
modos de utilización del sistema
•Diseñar la arquitectura del sistema
•Identificar los objetos principales del
sistema
•Desarrollar los modelos de diseño
•Especificar las interfaces de los objetos
Todas estas actividades se pueden ver
como actividades entrelazadas que
influyen entre sí. Los objetos se
identifican y las interfaces se
especifican completa o parcialmente en
el momento de definir la arquitectura del
sistema.
4.1 Estrategias 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 se proporciona una solución
más detallada de la solución. Una abstracción procedimental
se refiere a una secuencia de instrucciones que tiene una
función específica y limitada.
Una abstracción de datos es una colección nombrada de
datos que describe un objeto de datos. Por ejemplo, se
puede decir que la abstracción procedimental abrir
emplearía la información contenida en los atributos de la
abstracción de datos puerta.
4.1 Estrategias de diseño – Arquitectura
La arquitectura del software alude a la estructura general del
software y las formas en las 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.
4.1 Estrategias de diseño – 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.
4.1 Estrategias de diseño – 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).
4.1 Estrategias de diseño – Ocultación de información
El principio de 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.
4.1 Estrategias de diseño – Independencia funcional
Es la suma de directa de la modularidad y de los conceptos
de abstracción y ocultación de información. La
independencia funcional se consigue al desarrollar módulos
con una función determinante y una aversión a la interacción
excesiva con otros módulos. Los módulos independientes
son más fáciles de mantener, probar, modificar y se reduce
la propagación de errores.
4.1 Estrategias de diseño – Refinamiento
El refinamiento es una estrategia de diseño descendente. El
desarrollo de un programa se realiza al refinar de manera
sucesiva los niveles de detalle procedimentales. El
refinamiento hace que el diseñador trabaje sobre el
enunciado original y que proporcione más y más detalles
conforme se realiza cada refinamiento sucesivo. La
abstracción y el refinamiento son conceptos
complementarios.
4.1 Estrategias de diseño
La meta del diseño es crear un
modelo de software que
implemente todos los requisitos
del cliente de manera correcta y
complazca a aquéllos que lo
usen. El proceso de diseño
avanza de una visión general del
software a una visión más
estrecha que define el detalle
requerido para implementar un
sistema.
El proceso de diseño comienza con
un enfoque en la arquitectura. Se
definen los subsistemas, se
establecen mecanismos de
comunicación entre los subsistemas;
se identifican los componentes y se
realiza una descripción detallada de
cada componente. Además, se
diseñan las interfaces internas,
externas y del usuario.
4.2 Diseño de objetos
Un sistema orientado a objetos está
compuesto de objetos que
interactúan, los cuales mantienen
ellos mismos su estado local y
proveen operaciones sobre su
estado. La representación del estado
es privada y no se puede acceder a
ella directamente desde fuera del
objeto. El proceso de diseño de
objetos comprende el diseño de
clases de objetos y las relaciones
entre estas clases. El diseño
orientado a objetos comprende el
desarrollo de un modelo orientado a
objetos de un sistema de software
para implementar los requerimientos
identificados. Los objetos en un
diseño orientado a objetos están
relacionados con el problema a
resolver.
Un proceso general para el diseño
orientado a objetos puede contener las
siguientes etapas:
•Comprender y definir el contexto y los
modos de utilización del sistema
•Diseñar la arquitectura del sistema
•Identificar los objetos principales del
sistema
•Desarrollar los modelos de diseño
•Especificar las interfaces de los objetos
Todas estas actividades se pueden ver
como actividades entrelazadas que
influyen entre sí. Los objetos se
identifican y las interfaces se
especifican completa o parcialmente en
el momento de definir la arquitectura del
sistema.

Puedes darnos la bibliografía?
ResponderEliminarMuy buen artículo gracias