Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
fundamentos de los diseños de programas.
Tipo: Monografías, Ensayos
1 / 13
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
República Bolivariana de Venezuela Ministerio del Poder Popular para la Defensa Universidad Nacional Experimental Politécnica De la fuerza Armada Nacional Bolivariana Carrera: TSU Análisis y Diseño de Sistemas Área: Análisis y Diseño de Sistemas II UNEFA Profesor: Bachiller:
Víctor Velásquez Dairelys Martínez C.I: 28384910 Fundamentos de los diseños de programas Todo desarrollo, antes o después, se ve sometido a cambios sobre la funcionalidad inicial o simplemente se requiere funcionalidad nueva. Estos principios nos proporcionan unas bases para la construcción de aplicaciones mucho más sólidas y robustas. Permiten que los cambios y la evolución del software tengan un mínimo impacto en el código ya desarrollado tratando de evitar que lo que funciona deje de funcionar y por ello que el coste del mantenimiento sea mucho menor. A continuación pasamos a ver SOLID que es un acrónimo de 5 principios básicos en el diseño y programación orientada a objetos. Single responsibility (Principio de responsabilidad única): Este principio dice que cada clase tiene que tener una responsabilidad única y concreta, como dice Rober C. Martín “Una clase debería tener una y sólo una razón para cambiar”. Es común que cuando empezamos a desarrollar se acabe tomando decisiones como meter en una clase un método a causa de que esa clase lo utiliza, el problema llega cuando más adelante ese método lo necesitamos usar en otras clases y vemos que pierde coherencia. Supongamos que tenemos que realizar una aplicación para registrar las ofertas presentadas y las ventas cerradas. Se puede crear una clase vendedor con un método “Generar Oferta” que registrará las ofertas presentadas y otro “Cerrar Venta” que registrará las ofertas ganadas. Open-Close (Principio de abierto-cerrado): Lo que dice este principio es que no se debe modificar el código de una clase o entidad, sino que estas deben de ser extendidas y para que esto se cumpla, nuestro código debe estar bien diseñado. La forma más común para cumplir con este principio es el uso de la herencia y/o el de las interfaces. Cumplir el principio de responsabilidad única ayuda a que este otro principio también se cumpla, pero no significa que cumpliendo uno se cumpla el otro. Liskov Substitution (Principio de Sustitución de Liskov): Este principio recibe su nombre por su creadora Barbara Liskov. Viene a decir que una clase derivada de otra debe poder ser sustituida por su clase base y debemos garantizar que los métodos de la primera no provoquen un mal funcionamiento de los métodos de la clase base. Interface Segregation (Principio de Segregación de Interfaces): Mejor crear muchas interfaces que contengan pocos métodos, que crear pocas interfaces que definan demasiados métodos. El motivo de este principio es que ninguna clase debe de estar obligada a implementar métodos que no necesita, por ello
similares, es decir cada uno de estos Módulos están relacionados entre sí, por tanto estos módulos no son independientes, debido a esto resulta muy difícil modificarlos ya que el modificar alguno de los módulos, implica modificar todos los demás Módulos. Al aplicar la programación modular, un problema complejo debe ser dividido en varios subproblemas más simples, y estos a su vez en otros subproblemas más simples aún. Esto debe hacerse hasta obtener subproblemas lo suficientemente simples como para poder ser resueltos fácilmente con algún lenguaje de programación. Esta técnica se llama refinamiento sucesivo, divide y vencerás o análisis descendente (Top-Down). Un 'módulo' es cada una de las partes de un programa que resuelve uno de los subproblemas en que se divide el problema complejo original. Cada uno de estos módulos tiene una tarea bien definida y algunos necesitan de otros para poder operar. En caso de que un módulo necesite de otro, puede comunicarse con este mediante una interfaz de comunicación que también debe estar bien definida. Si bien un módulo puede entenderse como una parte de un programa en cualquiera de sus formas y variados contextos, en la práctica se los suele tomar como sinónimos de procedimientos y funciones. Pero no necesaria ni estrictamente un módulo es una función o un procedimiento, ya que el mismo puede contener muchos de ellos. No debe confundirse el término "módulo" (en el sentido de programación modular) con términos como "función" o "procedimiento", propios del lenguaje que lo soporte.
2. descomposición modular: La descomposición modular es un método de diseño proporciona un mecanismo sistemático para descomponer el problema en subproblemas, reducirá la complejidad de todo el problema consiguiendo de esta manera una solución modular efectiva. Consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea representa una actividad completa y se codifica de manera independiente. Facilita el diseño descendente del problema, centrándonos cada vez en la resolución de subproblemas de magnitud inferior. A la resolución de cada uno de estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y depurados independientemente, y a continuación se combinan uno a uno con otros módulos.
El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Ventajas Claridad Reducción de costos Reutilización Se siguen los siguientes pasos para poder realizar la descomposición modular: Identificar los módulos Describir cada módulo Describir las relaciones entre módulos Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad. Independencia funcional Acoplamiento Cohesión Comprensibilidad Adaptabilidad Independiente Funcional: Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada función será realizada en un módulo distinto. Si las funciones son independientes los módulos tendrán independencia funcional. Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión.
Baja: COHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares. Ejs.: módulos de E/S o de tratamiento de errores COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna La descripción del comportamiento de un módulo permite establecer el grado de cohesión: Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA Si contiene expresiones secuenciales (primero, entonces, cuando…), será temporal o secuencial Si la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión lógica Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal. Comprensibilidad: Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable: IDENTIFICACIÓN, el nombre debe ser adecuado y descriptivo DOCUMENTACIÓN, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código SIMPLICIDAD, las soluciones sencillas son siempre las mejores Adaptabilidad: La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad: PREVISIÓN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posible ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación CONSISTENCIA, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados
3. diseño asistido por herramientas CASE Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. En otras palabras Las Herramientas CASE son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases. La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas. Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales. o El empleo de herramientas CASE permiten integrar el proceso de ciclo de vida: Análisis de datos y procesos integrados mediante un repositorio. Generación de interfaces entre el análisis y el diseño. Generación del código a partir del diseño. Control de mantenimiento.
Herramientas de gestión de proyectos Herramientas de gestión y configuración de software (SCM) Herramientas de calidad y seguridad de software Herramientas de análisis y diseño Herramientas de desarrollo de interfaz de usuarios Herramientas para la Ingeniería de Software Orientada a Objetos Herramientas de integración y prueba Herramientas de métodos formales Herramientas Cliente/Servidor Herramientas de Ingeniería WEB Herramientas de Reingeniería Beneficios de las Herramientas CASE Entre los beneficios más significativos de las herramientas CASE se enumeran los siguientes: Facilidad para la revisión de aplicaciones La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente. Soporte para el desarrollo de prototipos de sistemas En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los
ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interface. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo. Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las características de entrada y salida son desarrolladas junto con el código orientado hacia los procedimientos y archivos de datos. Generación de código La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y las estructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar el código y los enlaces con otros módulos. Mejora en la habilidad para satisfacer los requerimientos del usuario Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las prácticas de desarrollo. Las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo. Soporte interactivo para el proceso de desarrollo La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.
4. generadores automaticos de codigos En un primer momento, los generadores de código nacen como una manera de agilizar el desarrollo, por ejemplo si siempre partimos de un caso en el que usamos 5 librerías y nuestro diseño es de cierta manera, para nosotros sería muy
La calidad del código, llegados a este punto muchos programadores avanzados pueden cuestionar, cómo de bueno es el código que generan estas herramientas. Desde Somos Binarios afirmamos que un programador avanzado y entendido en ese lenguaje, va a poder hacer código mucho mejor optimizado del que genera la máquina, porque puede adaptar mucho mejor el proyecto al lenguaje, mientras que el generador está pensado para que funcione en muchos proyectos muy distintos. Pero también es verdad, que un generador de código respecto a un usuario de nivel medio-bajo, posiblemente puede generar mejor código o por lo menos cometiendo un número sensiblemente inferior de errores. Los generadores basados en lenguajes formales como UML, necesitan conocer UML y esto no es una cosa que se aprenda en un par de semanas, sino que necesita un duro y continuo trabajo para poder dominarlo. Así que algunos casos, puede ser más rentable aprender la nueva tecnología que aprender UML.
