Este documento trata sobre los fundamentos del diseño de software y la programación orientada a objetos. Explica conceptos clave como abstracción, refinamiento, modularidad, diseño orientado a objetos, garantías de calidad de software, técnicas de prueba de software y mantenimiento de software. También cubre principios de diseño, métodos de análisis de requerimientos y la importancia de entender los objetos y sus interacciones en la programación orientada a objetos.

1. Instituto Universitario Politécnico
“Santiago Mariño”
Extensión Maracay
Escuela de Ingeniería de Sistemas
Maracay, Julio 2019
Fundamentos del Diseño del
Software
Docente:
José Castillo
Autor:
Luis Mortell
26.055.569

2. Introducción
En el universo de la programación actual, es de amplio consenso que
la programación orientada a objetos es el mejor paradigma disponible
para enfrentar las cada vez más complejas tareas de la programación.
Sin embargo, no todos los programadores tienen claro los fundamentos
de este paradigma, y tienden a confundir la programación usando
objetos con la programación orientada a objetos.
En Visual Basic, por ejemplo, se usan objetos (componentes) sin que
ello implique que estemos en presencia de un lenguaje orientado a
objetos. Programamos orientado a objetos cuando, usando un lenguaje
de programación, somos capaces de modelar el problema en términos
de objetos y sus relaciones. Es decir cuando cada entidad en
el programa es un objeto que brinda determinados servicios.

3. ¿Cuales son los Fundamentos del
Diseño de Software?
Entre los fundamentos de Diseño tenemos los siguientes:
1) Abstracción:
Cuando se considera una solución modular para cualquier problema,
pueden formularse varios niveles de abstracción. En el nivel superior de
abstracción se establece una solución en términos generales, en
lenguaje natural. En los niveles inferiores de abstracción se utiliza una
orientación más procedimental.
2) Refinamiento:
La arquitectura de un programa se desarrolla en niveles sucesivos de
refinamiento de los detalles procedimentales. Se desarrolla una
jerarquía descomponiendo una función de forma sucesiva hasta que se
llega a las sentencias del lenguaje de programación.

4. 3) Modularidad:
El software se divide en componentes con nombres y ubicaciones
determinados, que se denominan módulos y que se integran para
satisfacer los requisitos del proveedor. El software monolítico (es
decir, un programa grande compuesto de un solo módulo) no puede ser
estudiado fácilmente por un lector, ya que el número de caminos de
control, el número de variables y la complejidad global harían el
código prácticamente indescifrable.

5. Diseño Orientado a Objetos
La primera idea que se tiene al construir una solución de un
determinado problema es un modelo mental que constituye el primer
intento de diseño llamado comúnmente diseño informal. Este diseño a
medida que se va describiendo en papel utilizando técnicas y
procedimientos esquemáticos y metódicos va adquiriendo forma hasta
constituirse en un diseño formal equivalente.
Pues bien, dentro del paradigma de la orientación a objetos, el
diseño OO es con mucho; más complejo que el diseño estructurado
clásico, ya que lo que se busca es crear un diseño genérico y abierto y
no cerrado y concreto. El Diseño Orientado a Objetos se define como
un diseño de sistemas que utiliza objetos auto-contenidos y clases de
objetos.

6. Garantías de Calidad de Software
Consiste en los medios de la supervisión tecnología de dotación
lógica los procesos y los métodos aseguraban calidad. Hace esto por
medio de intervenciones de sistema de gerencia de la calidad debajo
de cuál se crea el sistema de software. Estas intervenciones son
movidas hacia atrás por unos o más estándares, generalmente ISO
9000.
La calidad del software es el conjunto de cualidades que lo
caracterizan y que determinan su utilidad y existencia. La calidad es
sinónimo de eficiencia, flexibilidad, corrección, confiabilidad,
mantenibilidad, portabilidad, usabilidad, seguridad e integridad.

7. Técnicas de Prueba de Software
1) Prueba unitaria:
Empecemos con el primero y más pequeño de todos – prueba
unitaria. La prueba unitaria se aplica en el elemento más pequeño de
un sistema, cada componente es testeado para asegurar que funciona
correctamente. Normalmente desarrolla una única función cohesiva.
La función de la prueba unitaria es de analizar cada pequeña parte y
testear que funciona correctamente.
2) Pruebas de Integración:
Es una extensión lógica de las pruebas unitarias. Dos unidades que
ya han sido testeadas y combinadas en un componente y su interface
son testeadas entre ellas. Un componente, en este ejemplo, se
refiere a un agregado que está integrado en más de una unidad, estas
son combinadas en componentes, que son agregadas por orden en
partes mas grandes del programa.

8. 3) Pruebas funcionales:
Las pruebas funcionales se basan en asegurarse de que todas las
características funcionen de cabo a rabo. Por ejemplo, testear que las
características de un usuario se actualicen cuando el usuario clicka en
el botón de guardar.
4) Pruebas de Rendimiento:
Y la última es la prueba de rendimiento. En el desarrollo de
software, la prueba de rendimiento es una práctica de test que
determina la actuación de un sistema en términos de respuesta y
estabilidad en una carga de trabajo en particular. También puede
servir para investigar, medir, validar o verificar otros atributos de
calidad del sistema, como la escalabilidad, seguridad y uso de
recursos.

9. Mantenimiento de Software
El mantenimiento de software es también una de las fases en el Ciclo
de Vida de Desarrollo de Sistemas (SDLC ó System Development Life
Cycle), que se aplica al desarrollo de software. La fase de
mantenimiento es la fase que viene después del despliegue
(implementación) del software en el campo.
La fase de mantenimiento de software involucra cambios al software
en orden de corregir defectos y dependencias encontradas durante su
uso tanto como la adición de nueva funcionalidad para mejorar la
usabilidad y aplicabilidad del software.

10. Principios y Especificaciones del
Diseño
El diseño del software es tanto un proceso como un modelo. El
proceso de diseño es una secuencia de pasos que hacen posible que el
diseñador describa todos los aspectos del software que se va a
construir.
El modelo de diseño es equivalente a los planes de un arquitecto
para una casa. Comienza representando la totalidad de todo lo que se
va a construir (por ejemplo, una representación en tres dimensiones
de la casa) y refina lentamente lo que va a proporcionar la guía para
construir cada detalle (por ejemplo, el diseño de fontanería).

11. Los principios del Diseño son los siguientes:
1. En el proceso deben tomarse enfoques alternativos.
2. Deberá rastrearse hasta el análisis.
3. Se debe reutilizar.
4. Tratar de imitar el dominio del problema.
5. Uniformidad e integración.
6. Deberá estructurarse para admitir cambios.
7. Debe prever la adaptación a circunstancias inusuales.
8. No codificar.
9. Evaluarse en función de calidad mientras está creciendo.
10. Minimizar errores conceptuales.

12. Métodos de Análisis de
Requerimientos
1) Descomposición Funcional:
La descomposición funcional se refiere al proceso de identificar y
resolver las relaciones funcionales en sus partes constituyentes, de tal
forma que la función global pueda ser reconstruida a partir de sus
partes.
2) Especificación vía Sentencias Textuales:
Es la forma tradicional de la especificación de requerimientos de
software.
3) Modelado del proceso:
Comprende la elaboración de diagramas de flujo de procesos
(Flujogramas) a partir de los requerimientos del software.

13. 4) Modelo de Dominio:
En Ingeniería de software, en análisis de dominio consiste en
analizar sistemas o software relacionados en un dominio, con la
finalidad de encontrar sus partes comunes y partes que los
diferencian.
5) Casos de Uso:
En el Lenguaje de Modelado Unificado (UML), un caso de uso es una
secuencia de interacciones entre un sistema y alguien o algo que usa
alguno de sus servicios.
6) Checklists:
La lista de chequeo (Checklist) consiste en una serie de preguntas
o revisiones que se realizan sobre los requerimientos de software, que
nos sean presentados de forma escrita.

14. 7) Inspección:
Revisión no destructiva de los requerimientos de software.
8) Prototipos:
Consiste en elaborar representaciones visuales (interfaz gráfica
con el usuario) de los requerimientos de software

15. Conclusiones
Para entender cómo funciona el paradigma de la programación
orientada a objetos es necesario ver un programa como una
colección de objetos que interactúan entre sí enviándose
mensajes y cambiando su estado durante la ejecución.
Resolver un problema bajo el paradigma de la programación
orientada a objetos implica determinar y caracterizar los
diferentes objetos que intervienen en el problema, definir sus
propiedades y métodos y ponerlos a interactuar.

16. Bibliografía
• Hernández, R. Y Fernández, C. (2017). Introducción a la
Ingeniería de Requerimientos. (Tercera Segunda Edición)
Argentina: Editorial Valley.
• Molina, C. (2017). Análisis y Fundamentos del Software.
Venezuela: Editorial Monumento.
• Romero, K. (2014). Diseño y Programación Orientada a
Objetos. México: Editorial El Bibliotecario.