Resumen Programación T1 PDF

Contenido 1 INTRODUCCIÓN. INGENIERÍA DEL SOFTWARE ...................................................................... 4 1.1 2 Introducción y perspectiva histórica ............................................................................. 4 1.1.1 Sistemas informaticos (SI) ...................

Contenido 1 INTRODUCCIÓN. INGENIERÍA DEL SOFTWARE ...................................................................... 4 1.1 2 Introducción y perspectiva histórica ............................................................................. 4 1.1.1 Sistemas informaticos (SI) ..................................................................................... 4 1.1.2 Elementos de un sistema informatico (SI) ............................................................ 4 1.1.3 Ingenieria del software ......................................................................................... 4 1.1.4 Perspectiva histórica ............................................................................................. 5 1.2 Mitos del software ........................................................................................................ 5 1.3 Formalización del proceso de desarrollo (MODELOS) .................................................. 5 1.3.1 Modelo en cascada................................................................................................ 5 1.3.2 Modelo en V .......................................................................................................... 6 1.3.3 Otros modelos ....................................................................................................... 6 1.3.4 Modelos Ágiles (MAS MODERNOS) ....................................................................... 7 1.3.5 Modelos Ágiles. Scrum .......................................................................................... 7 1.3.6 Modelos Ágiles. eXtreme Programming ............................................................... 7 1.3.7 Modelos Ágiles. Kanban ........................................................................................ 7 1.3.8 Combinación de Modelos...................................................................................... 8 1.4 Prototipos ...................................................................................................................... 8 1.5 Mantenimiento del software ........................................................................................ 8 1.5.1 Correcto ................................................................................................................. 8 1.5.2 Adaptivo ................................................................................................................ 9 1.5.3 Perfectivo .............................................................................................................. 9 1.6 Reingeniería................................................................................................................... 9 1.7 Calidad ........................................................................................................................... 9 1.7.1 Factores de calidad................................................................................................ 9 1.7.2 Plan de garantía..................................................................................................... 9 1.7.3 Revisiones y pruebas ............................................................................................. 9 ESPECIFICACIÓN DE SOFTWARE. ......................................................................................... 10 2.1 Modelado de sistemas ................................................................................................ 10 2.1.1 Objetivos ............................................................................................................. 10 2.1.2 Técnicas ............................................................................................................... 11 2.2 Análisis de requisitos ................................................................................................... 11 2.2.1 Objetivos del análisis ........................................................................................... 12 2.2.2 Tareas .................................................................................................................. 12 2.3 Notaciones .................................................................................................................. 12 2.3.1 Lenguaje natural .................................................................................................. 12 2.3.2 Diagrama de flujo ................................................................................................ 12 2.3.3 Diagrama transición de estados .......................................................................... 13 2.3.4 Descripciones funcionales. Pseudocódigo .......................................................... 14 2.3.5 Descripción de datos ........................................................................................... 14 2.3.6 Diagramas de datos (E-R) .................................................................................... 14 2.4 3 FUNDAMENTOS DEL DISEÑO DE SOFTWARE. ..................................................................... 14 3.1.1 Diseño .................................................................................................................. 14 3.1.2 Actividades del diseño ......................................................................................... 15 3.1.3 Producto final del diseño .................................................................................... 15 3.2 Abstracción .......................................................................................................... 15 3.2.2 Modularidad ........................................................................................................ 15 3.2.3 Refinamiento ....................................................................................................... 15 3.2.4 Estructuras de datos ............................................................................................ 16 3.2.5 Ocultación ........................................................................................................... 16 3.2.6 Genericidad ......................................................................................................... 16 3.2.7 Herencia .............................................................................................................. 16 3.2.8 Polimorfismo ....................................................................................................... 16 3.2.9 Concurrencia ....................................................................................................... 16 Notaciones para el diseño ........................................................................................... 16 3.3.1 Notaciones estructurales. ................................................................................... 17 3.3.2 Notaciones estáticas o de organización. ............................................................. 17 3.3.3 Notaciones dinámicas o de comportamiento. .................................................... 17 3.3.4 Notaciones híbridas. ............................................................................................ 17 3.4 5 Conceptos de base ...................................................................................................... 15 3.2.1 3.3 4 Documento de especificación de requisitos ............................................................... 14 Documentos de diseño................................................................................................ 17 TÉCNICAS DE DISEÑO DE SOFTWARE. ................................................................................. 17 4.1 DESCOMPOSICIÓN MODULAR. ................................................................................... 18 4.2 DISEÑO FUNCIONAL DESCENDENTE. .......................................................................... 18 4.3 DISEÑO BASADO EN ABSTRACCIONES. ....................................................................... 18 4.4 DISEÑO ORIENTADO A OBJETOS. ................................................................................ 19 4.5 DISEÑO DE DATOS. ...................................................................................................... 19 CODIFICACIÓN Y PRUEBAS. ................................................................................................. 19 5.1 CODIFICACIÓN. ............................................................................................................ 20 5.1.1 Lenguajes de programación ................................................................................ 20 6 5.1.2 Generaciones de los lenguajes de programación ............................................... 20 5.1.3 Lenguajes ............................................................................................................. 20 5.1.4 Lenguaje de alto nivel ......................................................................................... 21 5.1.5 Prestaciones de los lenguajes. Estructuras de control(I). ................................... 21 5.1.6 Prestaciones de los lenguajes. Concurrencia ...................................................... 21 5.1.7 Estructuras de datos. Variables ........................................................................... 22 5.2 PRUEBAS DE UNIDADES. ............................................................................................. 22 5.3 INTEGRACIÓN. ............................................................................................................. 23 5.4 PRUEBAS DE SISTEMA ................................................................................................. 23 AUTOMATIZACIÓN DEL PROCESO DE DESARROLLO. .......................................................... 24 6.1 Automatizacion. .......................................................................................................... 24 6.1.1 Entornos de desarrollo software. CASE............................................................... 24 6.1.2 Entornos integrados ............................................................................................ 24 TEMA 1 “DESARROLLO DE SOFTWARE. DOCUMENTACIÓN” 1.- INTRODUCCIÓN. INGENIERÍA DEL SOFTWARE. 2.- ESPECIFICACIÓN DE SOFTWARE. 3.- FUNDAMENTOS DEL DISEÑO DE SOFTWARE. 4.- TÉCNICAS DE DISEÑO DE SOFTWARE. 5.- CODIFICACIÓN Y PRUEBAS. 6.- AUTOMATIZACIÓN DEL PROCESO DE DESARROLLO. 1 INTRODUCCIÓN. INGENIERÍA DEL SOFTWARE 1.1 Introducción y perspectiva histórica 1.1.1 Sistemas informaticos (SI) Son SI aquellos que estan compuestos unicamente por computadores y sus periféricos. Los SI reallizan tareas de tratamiento de información: • • • Almacenamiento Elaboración Presentación de datos 1.1.2 Elementos de un sistema informatico (SI) El sistema informatico esta compuesto por materiales (FISICOS=Hardware) y los programas que controlan el funcionamiento de las computadoras (LÓGICO=Software) HARDWARE Y SOFTWARE Los procesos de fabricación de ambos difieren enormemente en costes. Cada copia de elemento hardware es altamente costosa. Las copias de elementos software son a coste cero y, además, no tienen “desgaste”. 1.1.3 Ingenieria del software Consiste en el empleo de técnicas y procedimientos tipicos de la ingeneria en general. El término Ingeniería de software apareció utilizado a finales de los años 60. 1.1.4 Perspectiva histórica • • • • • La elaboración de software se consideraba una actividad artesanal. Al aumentar la capacidad de los computadores por el avance del hardware se apreció la necesidad de una mejor organización en la producción de software, basada en: o La división del trabajo. o La organización del mismo. o Empleo de herramientas que automaticen labores triviales y repetitivas Esta organización dió lugar a Metodologías de Desarrollo. Las metodologías se empiezan a emplear en los 80, con la aparición de las herramientas CASE (Computer Aided Software Engineering). En los 90 se amplió el campo de acción de estas herramientas a todo el proceso completo, surgiendo las herramientas IPSE (Integrated Project Support Environment) y posteriormente las ICASE (Integrated CASE). 1.2 Mitos del software Cosas que NO son ciertas • • • • • El hardware es + importante que el software. El software es fácil de desarrollar. El software consiste exclusivamente en programas ejecutables. Los procedimientos a seguir por las personas que lo usan o la documentación generada también son software. El desarrollo de software es solo una labor de programación. Además de la codificación, las labores de Análisis y Diseño son fundamentales. Es natural que el software contenga errores. No es normal, no tiene que tener errores 1.3 Formalización del proceso de desarrollo (MODELOS) 1.3.1 Modelo en cascada Modelo más antiguo y base para los siguientes (posteriores) 1.3.2 Modelo en V Se basa en una secuencia de fases análoga a la del modelo en cascada, importa más la visión jerarquizada. Parte izquierda = Cascada 1.3.3 Otros modelos Diseño en Espira 1. Comunicación con el cliente 2. Planificación. Sirve para establecer el contexto del desarrollo. 3. Análisis de riesgo. Evalúa alternativas para la parte del desarrollo elegida. Seleccionando la + ventajosa. a. Punto entrada del proyecto 4. Ingeniería. Corresponden a las indicadas en los modelos clásicos. Cada ciclo se obtiene una versión + completa. (análisis, diseño, codificación) 5. Evaluación del cliente. Analizan los resultados de la fase de ingenería. Con la colaboración del “cliente” 6. Construcción y entrega Repetir el ciclo unas cuantas veces. Como un modelo de cascada, pero se repite. - Introduce como elemento distinto el Análisis de riesgo. - Desarrollado por Boehm - En cada ciclo se realiza el desarrollo completo. 1.3.4 Modelos Ágiles (MAS MODERNOS) El desarrollo ágil es una metodología de ingeniería de software que prioriza la iteración, la adaptabilidad y la colaboración en equipos multidisciplinarios para evolucionar los proyectos de software. Los requisitos y soluciones evolucionan con el tiempo según la necesidad. 1.3.5 Modelos Ágiles. Scrum Metodología de trabajo colaborativo. Caracteristicas: 1. Estrategia de desarrollo incremental 2. Calidad del resultado + en el conocimiento tácito de las personas en eq. Auto organizados 3. Solapar las diferentes fases del desarrollo. (diferencia de ciclo secuencial o cascada) 1.3.6 Modelos Ágiles. eXtreme Programming La programación extrema es una metodología que selecciona y aplica las prácticas más eficaces para un proyecto de manera dinámica a lo largo de su desarrollo. - Metodología de desarrollo de la ingeniería de software. Desarrollada por Kent Beck. - Se diferencia de la tradicional por que se enfoca en la adaptabilidad que en la previsibilidad. (Se enforca mas en adaptarnos al cambio que cambiarlo. - El cambio se puede realizar en cualquier punto del proyecto. 1.3.7 Modelos Ágiles. Kanban Kanban es un sistema de programación para lean y otros procesos JIT. Existen “Tarjetas” físicas o virtuales llamadas Kanbanse mueven de principio a fin. Su objetivo es tener un flujo constante. No es estanco. 1.3.8 Combinación de Modelos Resulta mas ventajoso aprovechar las ventajas de varios modelos diferentes, combinándolos en un modelo mixto de ciclo de vida. La espiral es de alguna manera una combinación de modelos. 1.4 Prototipos Se suelen usar en sistemas innovadores, donde no hay una experiencia previa. “Un prototipo es un sistema auxiliar que permite probar experimentalmente ciertas soluciones parciales a las necesidades del usuario o a los requisitos del sistema.” Dos tipos de prototipos: 1. Prototipos rápidos: 1. Su finalidad es solo adquirir experiencia. 2. No se usarán en el producto final. 3. Se denominan también prototipos de usar y tirar (throw-away) y maquetas (mockup). 4. En las fases de análisis y diseño se emplean para explorar alternativas. Se usa en las primeras fases 5. Lo importante de estos prototipos es desarrollarlos en poco tiempo. Ver si vamos bien o no, tiene que ir rápido 2. Prototipos evolutivos: 1. Se trata de aprovechar al máximo su código. 2. Se desarrolla sobre el mismo soporte hardware/software que el sistema final. 3. Se construye tras unas fases parciales de análisis y diseño. 4. Se construyen así sucesivas versiones del prototipo hasta convertirlo en el sistema final. 5. Los documentos de especificación, diseño… se desarrollan progresivamente con cada nuevo prototipo. 6. Esta forma de desarrollo puede formalizarse en un modelo de ciclo de vida evolutivo. Este modelo es un proceso iterativo en bucle sobre el modelo en cascada, avanzando un poco en cada fase. 1.5 Mantenimiento del software Tipos de mantenimiento con diferentes objetivos: 1. Mantenimiento correctivo 2. Mantenimiento adaptativo 3. Mantenimiento perfectivo. 1.5.1 Correcto Su finalidad es corregir errores, que no han sido detectados y eliminados en el desarrollo inicial. 1.5.2 Adaptivo Exige modificar parcial o totalmente la aplicación para adaptarla a las nuevas características si se quiere seguir utilizando. 1.5.3 Perfectivo En aplicaciones sujetas a competencias de mercado. También en aplicaciones en que las necesidad del usuario evolucionan. 1.6 Reingeniería Software creado de manera artesanal, sin ninguna documentación. ¿Que hago con él? Hacer una ingeniería inversa (Reingeniería), algo que ya está hecho mejorarlo y documentar todo lo posible. 1.7 Calidad En el modelo de ciclo de vida hay actividades típicamente productivas, como el análisis, diseño y codificación, y otras cuyo objetivo es controlar la calidad del producto, tales como las revisiones y pruebas. 1.7.1 Factores de calidad La calidad del software está regida por la norma ISO 25000. 1.7.2 Plan de garantía El desarrollo del software debe estar en un documento formal llamado Plan de Garantia de Calidad de Software (SQAP) Este documento SQAP debe aspectos como: 1. La organización de los equipos y personas y la dirección y seguimiento del desarrollo. 2. Modelo del ciclo de vida a seguir, con detalle de sus fases y actividades. 3. Documentación requerida. Contenidos de cada documento y guiones. 4. Organización de las pruebas a realizar sobre el producto de software a distintos niveles. 5. Organización de la etapa de mantenimiento, especificando cómo ha de gestionarse la realización de cambios sobre el producto ya en explotación. 1.7.3 Revisiones y pruebas Recomendaciones al realizar las REVISIONES del software: 1. Deben ser realizadas por un grupo de personas.varias personas 2. El grupo de personas para la revisión ha de ser reducido.otro debe hacer la revision disitnto al que creo el producto 3. NO debe ser realizada por los autores del producto.se revisa el producto, resultado final 4. Se debe revisar el producto, NO el productor ni el proceso de producción. 5. Debe establecerse de antemano una lista formal de comprobaciones a realizar. 6. Debe levantarse acta de la reunión de revisión. PRUEBAS: Su objetivo es descubrir los errores que pueda contener un software. NO permiten garantizar la calidad de un producto. Es una técnica fundamental de la garantía de calidad. 2 ESPECIFICACIÓN DE SOFTWARE. Es la labor de análisis y definición de los requisitos que ha de cumplir un proyecto. Se debe realizar en la primera fase. 2.1 Modelado de sistemas Su objetivo es entender el funcionamiento requerido y facilitar la comprensión de los problemas planteado. Establecer modelos conceptuales que reflejen la organización de información y por otro lado las diversas transformaciones. 2.1.1 Objetivos Un modelo conceptual es el que nos permite una abstracción lógico-matemática del mundo real Un modelo de software establece y especifica las propiedades y restricciones del sistema. Debe explicar QUÉ debe hacer el sistema y no el CÓMO, que se establecerá en la etapa de diseño. Objetivos a cubrir con un modelo: 1. Facilitar la comprensión del problema a resolver. 2. Establecer un marco que simplifique y sistematice el análisis inicial y las futuras revisiones. 3. Fijar las bases para realizar el diseño. 4. Facilitar la verificación del cumplimiento de los objetivos del sistema. 2.1.2 Técnicas 2.1.2.1 Descomposición. Modelo jerarquizado Ante un problema la 1º técnica es descomponerlo en otro + sencillo. De esta manera el problema se divide en subproblemas. (Modelo jerarquizado). Existe la descomposición funcional = HORIZONTAL (Empresa> Nomina(Pagos IRP, realización de nominas..) Si se descompone un modelo para ver su estructura, se le denomina VERTICAL 2.1.2.2 Aproximaciones sucesivas Se puede crear un modelo de partida basado en la forma de trabajo anterior (Software sustituido) que podrá ser depurado mediante aproximaciones sucesivas hasta alcanzar el modelo final. Para el analista es fundamental contar con la colaboración de alguien que conozca muy bien el sistema anterior y que sea capaz de incorporar mejoras. 2.1.2.3 Empleo de diversas notaciones En modelos muy complejos es posible que sea necesario utilizar varias notaciones, notaciones alternativas o complementarias: “El lenguaje natural, esquemas, figuras, o cualquier recurso que facilite la comprensión”. Las herramientas de modelado CASE combinan texto, tablas, diagramas, gráficos, etc. 2.1.2.4 Análisis del dominio Se entiende por dominio el campo de aplicación del sistema a desarrollar. Es aconsejable estudiar: 1. 2. 3. 4. Normativa que afecte al sistema. Otros sistemas semejantes. Estudios recientes en el campo de la aplicación. Bibliografía clásica y actualizada. El estudio del análisis del dominio tiene como ventajas: 1. Facilitar la comunicación entre analista y usuario. 2. Creación de elementos realmente significativos del sistema. 3. Reutilización posterior del software desarrollado. 2.2 Análisis de requisitos Se trata de caracterizar el problema a resolver. 2.2.1 Objetivos del análisis Obtener las especificaciones que debe cumplir el sistema a desarrollar. Para lograr una especificación correcta, el modelo global del sistema deberá tener las siguientes propiedades: 1. 2. 3. 4. 5. 6. 7. 8. Completo y sin omisiones. Conciso y sin trivialidades. Sin ambigüedades. Sin detalles de diseño o implementación. Fácilmente entendible por el cliente. Separando requisitos funcionales y no funcionales. Dividiendo y jerarquizando el modelo. Fijando los criterios de validación del sistema. 2.2.2 Tareas 1. 2. 3. 4. 5. 6. Estudio del Sistema en su contexto. Identificación de necesidades. Análisis de alternativas. Estudio de viabilidad. Establecimiento del modelo del sistema. Modelo jerarquizado Elaboración del Documento de Especificación de Requisitos. Revisión continuada del Análisis. 2.3 Notaciones Entendibles por el clientes, el usuario y por todo aquel que participe en el proceso del análisis y desarrollo del sistema. 2.3.1 Lenguaje natural Utilizado para aclarar cualquier aspecto del sistema cuando no es posible con notaciones. El Lenguaje Natural estructurado = Notacion mas formal. “SI _____ ENTONCES _____” 2.3.2 Diagrama de flujo Años 70 El enfoque del análisis estructurado es considerar que un sistema software se puede modelar mediante el flujo de datos que entra al sistema 2.3.3 Diagrama transición de estados El diagrama de transición de estados es la notación específica para describir el comportamiento dinámico del sistema a partir de los estados elegidos como más importantes. 2.3.4 Descripciones funcionales. Pseudocódigo En las descripciones funcionales se realizan utilizando un Lenguaje Natural Estructurado y notaciones precisas llamadas Pseudocodigo. Pseudocódigo es una notación basada en un lenguaje programación estructurado. Maneja datos en general, sin una sintaxis estricta permitiendo el uso de lenguaje natural cuando sea necesario. 2.3.5 Descripción de datos Detallar la estructura interna de los datos mediante los diccionarios de datos. No importa el formato todas describir el dato: 1. Nombre 2. Utilidad 3. Estructura 2.3.6 Diagramas de datos (E-R) Permite definir todos los datos que manejara el sistema junto con las relaciones que hay entre ellos. 2.4 Documento de especificación de requisitos El Documento de Especificación de Requisitos (SRD o SRS). En un único documento recoge el trabajo realizado durante la etapa de análisis del sistema. 3 FUNDAMENTOS DEL DISEÑO DE SOFTWARE. Estaba del diseño que determina COMO se resuelve el proyecto. 3.1.1 Diseño Descripción o bosquejo del sistema a desarrollar. La descripción se debe hacer mediante notaciones formales. El punto de partida del diseño es el documento de especificación de requisito (SRD. Pasaremos del QUE al COMO. 3.1.2 Actividades del diseño 1. DISEÑO ARQUITECTÓNICO. Aspectos estructurales y de organización del sistema y posible división en subsistemas o módulos. 2. DISEÑO DETALLADO. Organización de los módulos 3. DISEÑO PROCEDIMENTAL. Organización de las operaciones o servicios que ofrecerá cada uno de los módulos. 4. DISEÑO DE DATOS. Organización de la Base de Datos del sistema, partiendo del diccionario de datos y el diagrama E-R. 5. DISEÑO DE LA INTERFAZ DE USUARIO. Se tienen en cuenta incluso factores psicológicos. 3.1.3 Producto final del diseño El resultado de las cinco actividades del diseño dará lugar a una especificación muy formal de la estructura del sistema y de cada uno de sus elementos. Esto constituye el “producto del diseño” y se recogerá en el Documento de Diseño de Software (SDD:Software Design Document/Software Design Description). Las normas ESA establecen dos documentos de diseño de software: 1. Documento de Diseño Arquitectónico. (ADD:Architectural Design Document). 2. Documento de Diseño Detallado. (DDD: Detailed Design Document). A éste se pueden añadir como apéndices los listados de los programas una vez completado el desarrollo. 3.2 Conceptos de base Abstracción Estructuras de datos Herencia Modularidad Ocultación Polimorfismo Refinamiento Genericidad Concurrencia 3.2.1 Abstracción Consiste en identificar los elementos significativos del lo que consta el sistema y absorber la utilidad de cada uno. Se utilizan: 1. Abstracción funcionales 2. Tipos abstractos 3. Maquinas abstractas 3.2.2 Modularidad Conseguir la coordinación de muchas personas trabajando simultáneamente. Ventaja de un diseño modular: 1. Claridad 2. Reducción de costos 3. Reutilización 3.2.3 Refinamiento Se refina una idea no muy concreta hasta perfilar el más mínimo detalle. La forma natural de acercar el lenguaje natural del documento SRD al lenguaje de programación es utilizando el refinamiento. 3.2.4 Estructuras de datos La organización de la información es esencial. Una mala decisión de la misma puede dar al traste con todo el proyecto. Estructuras fundamentales: Registos Arboles Conjuntos Grafos Formaciones Tablas Lista, pilas, colas Ficheros 3.2.5 Ocultación Para utilizar adecuadamente un programa no es necesario conocer su estructura interna. Solo precisa conocer su interfaz. En la interfaz se muestra lo que permanecerá invariable con cualquier cambio. Las ventajas de aplicar este concepto son: 1. depuración 2. Mantenimiento 3.2.6 Genericidad Un enfoque posible del diseño es agrupar aquellos elementos del sistema que utilizan estructuras semejantes o necesitan un tratamiento similar 3.2.7 Herencia Principio de la programación donde se crean relaciones de jerarquía entre elementos o clases. Un elemento "padre" ofrece una base de estructuras y operaciones, y los elementos "hijos" toman esa base, pudiendo añadir o modificar características para adaptarse a sus propias necesidades. Es como una familia donde los hijos reciben características de los padres y pueden desarrollarlas más allá. 3.2.8 Polimorfismo El elemento que puede cambiar su forma sin variar su naturaleza. Posibilidades del software: 1. La Generidad explicada previamente es una forma de lograr que un elemento genérico adquiera distintas formas al ser particularizado. 2. El polimorfismo esta muy unido al concepto de herencia. 3. Existe la Sobrecarga. En este caso quienes adquieren múltiples formas son los operadores, funciones o procedimientos. 3.2.9 Concurrencia Aprovechar la capacidad de proceso del cómputo de los equipos actuales. 3.3 Notaciones para el diseño El objetivo de cualquier notación es resultar precisa, clara y sencilla de interpretar en el aspecto concreto que describe Clasificaremos las notaciones en: Estructurales Estáticas/Organización Dinámicas/comportamiento Hibridas 3.3.1 Notaciones estructurales. Sirven para cubrir un primer nivel de diseño arquitectónico y con ella se trata de desglosar y estructurar el sistema en sus partes fundamentales. Notaciones más formales: 1. Diagramas de estructura. 2. Diagramas HIPO. 3. Diagramas de Jackson. 3.3.2 Notaciones estáticas o de organización. Estas notaciones sirven para describir características estáticas del sistema, tales como la organización de la información Se emplean las mismas notaciones empleadas para realizar la especificación: 1. Diccionario de Datos. 2. Diagramas Entidad-Relación. 3.3.3 Notaciones dinámicas o de comportamiento. Estas notaciones permiten describir el comportamiento del sistema durante su funcionamiento Notaciones empleadas: 1. Diagramas de Flujo de Datos. 2. Diagramas de Transición de Estados. 3. Lenguaje de Descripción de Programas (PDL). 3.3.4 Notaciones híbridas. Estas notaciones tratan de cubrir simultáneamente aspectos estructurales, estáticos y dinámicos. Notaciones utilizadas: 1. Diagramas de abstracciones. Contiene nombre contenido y operaciones. 2. Diagramas de objetos. = que las abstracciones 3.4 Documentos de diseño El resultado de la etapa de diseño se recoge en un documento que se utilizará en las restantes etapas del proyecto y que se denomina Software Design Document (SDD). La ESA establece el empleo de un Architectural Design Document (ADD) y un Detailed Design Document (DDD). 4 TÉCNICAS DE DISEÑO DE SOFTWARE. Todas las técnicas tratan de conseguir como objetivos inmediatos: 1. La descomposición modular del sistema. 2. La decisión sobre aspectos de implementación. 4.1 DESCOMPOSICIÓN MODULAR. Todas las técnicas de diseño están de acuerdo en la necesidad de la descomposición modular, para la que es necesario: 1. Identificar los Módulos 2. Describir cada Módulo 3. Describir las relaciones entre ellos. Cualidades mínimas de una descomposición modular para que sea válida: 1. 2. 3. 4. 5. Independencia funcional. Acoplamiento (interrelación). Cohesión. Comprensibilidad. Adaptabilidad. 4.2 DISEÑO FUNCIONAL DESCENDENTE. Estas técnicas incluyen todas aquellas en las que la descomposición se realiza desde un punto de vista funcional: - Desarrollo por refinamiento progresivo. - Programación estructurada de Jackson. - Diseño Estructurado. 4.3 DISEÑO BASADO EN ABSTRACCIONES. Estas técnicas surgen cuando se identifican con precisión los conceptos de abstracción de datos y de ocultación. Descomposición modular basada en abstracciones. Consiste en dedicar módulos separados a la realización de cada tipo abstracto de datos y cada función importante. Se puede realizar de forma descendente o ascendente Método de Abbott. Sugiere una forma más metódica y formal que el diseño anterior, trata de conseguir una guía para ir reconociendo aquellos elementos del sistema que se pueden considerarse abstracciones. Partiendo de un texto conteniendo la especificación informal, identificar palabras que puedan corresponder a elementos significativos del diseño. Tipos de datos Tipos de datos = Sustantivos Atributos Atributos = Sustantivos o adjetivos Operaciones Operaciones = Verbos o nombres de acciones. 4.4 DISEÑO ORIENTADO A OBJETOS. El diseño orientado a objetos es igual al diseño basado en abstracciones con la diferencia de que se añaden algunas características adicionales propias de los objetos como la herencia y el polimorfismo. Todas las metodologías orientadas a objetos son similares, teniendo como elementos comunes: 1. Estudiar y comprender el problema. 2. Desarrollar una posible solución. 3. Identificar las clases y objetos. a. Identificar las operaciones sobre los objetos. b. Aplicar herencia. c. Describir las operaciones. d. Establecer la estructura modular. 4.5 DISEÑO DE DATOS. Los dos aspectos más importantes a tener en cuenta en el diseño de una base de datos relacional son: 1. Las formas normales. 2. Diagramas de Entidad-Relación 5 CODIFICACIÓN Y PRUEBAS. Codificación Esta fase es el núcleo central de cualquier de los modelos de desarrollo de software: ciclo de vida, prototipos, modelo en espiral… Hasta los 70 el desarrollo del software se centraba en la codificación. Pruebas Al finalizar la codificación e integración se prueba el software para comprobar que cumple con los requisitos. 5.1 CODIFICACIÓN. 5.1.1 Lenguajes de programación Son el medio fundamental que tenemos para realizar la codificación. 5.1.2 Generaciones de los lenguajes de programación Los lenguajes de primera generación - 1GL, son lenguajes de bajo nivel conocidos como lenguaje de máquina lenguaje binario. Se utilizan para programar las computadoras a un nivel muy bajo de abstracción. Los lenguajes de segunda generación - 2GL, también son lenguajes ensambladores de bajo nivel. Se usan en kernels y unidades de hardware, además de ser usados comúnmente para edición de video, gráficos y videojuegos. Los lenguajes de tercera generación - 3GL, son lenguajes de alto nivel, como C, C++, C#, Java, BASIC, JavaScript y Visual Basic. Los lenguajes de cuarta generación - 4GL, son lenguajes que consisten en declaraciones similares a las declaraciones hechas en un lenguaje humano. Los lenguajes de cuarta generación se usan comúnmente en la programación de bases de datos y los ejemplos de scripts incluyen Unix Shell, Perl, PHP, Python, Ruby y SQL. Los lenguajes de quinta generación - 5GL, son lenguajes de programación que contienen herramientas visuales para ayudar a desarrollar un programa. Ejemplos de lenguajes de quinta generación incluyen Mercury, OPS5 y Prolog. En resumen, los lenguajes de las generaciones 1GL y 2GL son también de bajo nivel y los de las generaciones 3GL, 4GL y 5GL son de alto nivel. 5.1.3 Lenguajes 5.1.4 Lenguaje de alto nivel La sintaxis se aproxima cada vez más al lenguaje natural y su estructura evoluciona. Los lenguajes de alto nivel buscan ser independientes del hardware en el que se ejecutan, ocultando sus complejidades al programador para que pueda centrarse en el problema a resolver. De este modo se consigue también que sean multiplataforma de modo que pueden ejecutarse en diferentes máquinas a pesar de sus diferencias internas 5.1.5 Prestaciones de los lenguajes. Estructuras de control(I). Programación estructurada: - Secuencia. Se escriben las sentencias una tras otra. - Selección. Mediante construciones tipo if-then-else. - Iteracción. Mediante sentencias tipo while-do. - Selección general. Sentencias tipo if-then-elseif-then...else. - Selección por casos. Mediante sentencias case-of. - Repetición. Tipo repeat–until. - Bucles con contador. Del tipo for-to-do. - Bucles indefinidos. Sentencias como loop / exit. Manejo de excepciones. Durante la ejecución de un programa se pueden producir errores o sucesos inusuales que se denominan genéricamente excepciones. Ejemplos: - Errores humanos. - Fallos hardware. - Errores software. - Datos de entrada vacíos. - Valores fuera de rango. 5.1.6 Prestaciones de los lenguajes. Concurrencia Dos o mas procesos decimos que son concurrente, paralelos, o que se ejecutan concurrentemente, cuando son procesados al mismo tiempo, para que ejecutar uno de ellos, no hace falta que se vaya ejecutado el otro. En el proceso de codificación se resolverán los problemas de concurrencia: - Tareas que se deben ejecutar concurrentemente. - Sincronización de tareas. - Comunicación entre tareas. - Interbloqueos (deadlock). Codificando para ello: - Semáforos. (Se puede pasar o no se puede pasar, si pero con pegas) - Monitores. Monitorea los procesos - Pasos de mensajes. 5.1.7 Estructuras de datos. Variables 1. Datos simples: 1.1. Enteros 1.1.1.Normal 1.1.2.Corto 1.1.3.Largo 1.2. Caracteres “una A un numero 1 o /” 1.3. Cadenas de caracteres (strings) “Juuntar más de dos caracteres” 2. Datos compuestos: 2.1. Vectores y matrices (arrays) 2.2. Registros (heterogéneos) 2.3. Datos dinámicos 2.4. Constantes 2.5. Tipos abstractos (Objetos) 5.2 PRUEBAS DE UNIDADES. Con el fin de evitar el posible caos de una prueba global única, se deben hacer pruebas a cada unidad o módulo según se avanza en la codificación del proyecto. Para elaborar los casos de prueba se tendrá en cuenta: 1. 2. 3. 4. 5. 6. Una buena prueba encuentra errores y no los encubre. Para detectar el error hay que conocer el resultado correcto. Es aconsejable que no participen en la prueba el codificador o diseñador. Siempre hay errores. Si no aparecen, se deben diseñar pruebas mejores. Al corregir un error pueden aparecer otros nuevos. Es imposible demostrar la ausencia de defectos mediante pruebas. Las técnicas de prueba unitaria responden a dos estrategias fundamentales: 1. Pruebas de “caja negra”. Ignora por completo la estructura interna del programa y se centra en la especificación entrada-salida del software. 2. Pruebas de “caja blanca o transparente”. Se conoce y se tiene en cuenta la estructura interna del módulo. 5.3 INTEGRACIÓN. Técnicas de integración de software: - Integración BigBang. Consiste en realizar la integración de todas las unidades en un único paso. - Integración descendente. Se parte inicialmente del módulo principal que se prueba con módulos de “andamiaje” o sustitutos (stubs) que se van reemplazando por los verdaderos y realizando sus pruebas de integración. - Integración ascendente. Se codifican por separado y en paralelo los módulos de nivel más bajo y se van integrando hacia niveles superiores, elaborando a veces módulos integradores que después se sustituirán por los definitivos. 5.4 PRUEBAS DE SISTEMA Tipos de pruebas en función del objetivo: 1. De recuperación. Pretenden medir la capacidad del sistema para recuperarse ante fallos. 2. De seguridad. Para medir la protección contra un acceso o manipulación no autorizados. 3. De resistencia. Para comprobar el comportamiento del sistema frente a situaciones excepcionales. 4. De sensibilidad. Para testear el tratamiento que da el sistema a ciertas singularidades relacionadas con los algoritmos matemáticos utilizados. 5. De rendimiento. Para comprobar las prestaciones del sistema que son críticas en tiempo. Pruebas alfa y beta. Para comprobar que el producto final es útil para los usuarios, estos últimos deben intervenir en las pruebas finales del sistema. 1. Se denominan pruebas alfa a una primeras pruebas que se realizan en un entorno controlado donde el usuario tiene el apoyo de alguna persona del equipo de desarrollo que seguirá muy de cerca dichas pruebas. 2. Se llaman pruebas beta a las que se realizan posteriormente a las alfa, en las que uno o varios usuarios trabajan en su entorno normal, sin apoyo de nadie y anotando todos los problemas que puedan surgir. 6 AUTOMATIZACIÓN DEL PROCESO DE DESARROLLO. Ayuda recibida de las herramientas de software que facilitan la labor de todas las fases del desarrollo de Software. 6.1 Automatizacion. 6.1.1 Entornos de desarrollo software. CASE Un entorno de desarrollo software (SEE:Software Engineering Environment) consiste en el conjunto de elementos para realizar dicho desarrollo, en especial los elementos informáticos que facilitan esa labor. Las técnicas y herramientas de soporte informático de desarrollo de software se denominan CASE (Computer Aided Software Engineering). 6.1.2 Entornos integrados Las fases que debe contemplar un buen entorno de desarrollo son: 1. Análisis y Diseño. 2. Entorno de Programación. a. Verificación y Validación. 3. Construcción de interfaz de usuario. 4. Gestión de configuración 5. Ingeniería inversa. 6. Gestión de Proyectos.