Relación con otras asignaturas del plan de estudio Anteriores Posteriores Planificación y modelado Redes de computadoras Tópicos selectos de programación interfaces. Desarrollo sustentable Ética

Objetivo(s) general(es) del curso El estudiante diseñará y construirá un proyecto de software conforme a los requerimientos establecidos en el dominio del proyecto de software.

Temario Unidad Tema Subtemas 1 2 3 Conceptos introductorios Diseño orientado a objetos Construcción 1.1 La arquitectura de 4+1 vistas. 1.2 Desarrollo orientado a objetos 1.3 Diagramación 2.1 Diseño del sistema en base a procesos 2.1.1 Actividades y casos de uso. 2.1.2 Interfaces de usuario 2.2 Diseño de la lógica 2.2.1 Clases y objetos 2.2.2 Interacción 2.2.3 Estados y transiciones 3.1 Despliegue de componentes y arquitectónico 3.2 Técnicas de desarrollo de las arquitecturas de referencia en diferentes dominio 3.2.1 Los modelos de componentes 3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentación. 3.2.3 Arquitectura de referencia para sistemas móviles con conexión a internet 3.2.4 Arquitectura de referencia para sistemas de información. 3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje 3.2.6 Arquitecturas de referencia para líneas de productos.

Temario Unidad Tema Subtemas Pruebas de Software Modelos de proceso de 4 5 Pruebas de Software Modelos de proceso de software. Implantación y mantenimiento 4.1 Definiciones 4.1.1 Prueba, caso de prueba defecto, falla error, verificación, validación 4.1.2 Relación entre defecto-falla-error 4.1.3 Pruebas estructurales, funcionales y aleatorias 4.1.4 Documentación del diseño de las pruebas 4.2 Proceso de pruebas 4.2.1 Generar un plan de pruebas 4.2.2 Diseñar pruebas especificas 4.2.3 Tomar configuración del software a probar 4.2.4 Configurar las pruebas 4.2.5 Evaluar resultados 4.2.5.1 Depuración 4.2.5.2 Análisis de errores 4.3 Técnicas de diseño de casos de pruebas 4.4 Enfoque práctica recomendado para el diseño de casos 4.5 Estrategias de aplicación de la pruebas 4.5.1 De unidad 4.5.2 De integración 4.5.3 Del sistema 4.5.4 De aceptación 5.1 Implantación e integración de casos de uso y componentes de software 5.2 mantenimiento del software.

Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones} Unidad 1.Conceptos Introductorios fdf 1.1 La arquitectura de 4+1 vistas La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema Perry y Wolf (1992) describen una arquitectura software como:   Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones} Es muy complejo capturar la arquitectura software en un sólo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y características de la arquitectura en múltiples vistas. Una vista es “una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva” (Kruchten, 1995). El modelo más aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1 .

Vista de Implementación Requisitos Clases Datos Componentes Casos de Uso Escenarios Vista Estructural (Lógica) Vista de Implementación Vista de Casos de Uso Vista de Procesos (Dinámica) Vista de Despliegue Interacción (Colaboración y secuencia) Actividades Estados Despliegue Modelos Lógicos Modelos Físicos

Vista estructural. Es todo lo que rodea al sistema en desarrollo, es decir las clases; por ejemplo personas, cuentas, personal, material, etc, <<Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares>>. Vista de Casos de Uso.- Es una descripción de las acciones de un sistema desde el punto de vista del usuario, es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. La finalidad de este es crear una visión por publico en general y no por expertos en computación. Vista de Procesos.- En estos diagramas se representan los estados en que se encuentran los objetos. Por ejemplo el objeto articulos sus estados probables son agotados, vendidos, etc. En los diagramas de secuencias se indican claramente las interacciones de entre los tiempos de los distintos estados de los objetos y clases. Y en el de actividades se representan las fases o los pasos de un proceso .

Vista de Implementación. - Los diagramas de componentes ilustran las Vista de Implementación.- Los diagramas de componentes ilustran las organizaciones y las dependencias entre los componentes de software. Un componente debe de ser Código fuente componente Componentes en tiempo de ejecución Componente ejecutable Vista de despligue.- El diagrama de despliegue o emplazamiento muestra la configuración de los elementos de proceso en tiempo de ejecución y los procesos de software que habitan en el. El diagrama de despliegue visualiza la distribución de componentes a través de la empresa.

1.2 Desarrollo orientado a objetos El análisis orientado a objetos es un método de análisis que examina los requisitos desde la perspectiva de las clases y los objetos que se encuentran en el vocabulario del dominio del problema. El diseño a objetos es un método de diseño que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógicos y físicos, así como los modelos estático y dinámico del sistema que se diseña.

Cuestiones para iniciar la construcción de un proceso de sw ¿Qué es lo que va a construir? ¿Cómo lo va a construir? ¿Qué tecnología usará? ¿Cómo lo documentará?

1.3 Diagramación ¿Qué es UML? UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. El UML nos permite mediante diagramas, plasmar de una forma detallada e inteligible la solución al problema planteado.

1.3 Diagramación Los diagramas tienen como objetivo presentar diversas perspectivas de un sistema. A esto se le llama Modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto con la interpretación del artista del edificio. Tenemos que tener en cuenta que un modelo UML describe lo que supuestamente hará un sistema, pero no dice como implementar dicho sistema.

Diagramas de UML Los diagramas expresan gráficamente partes de un modelo State Diagrams Diagramas de Clases Use Case Diagrams Use Case Diagrams State Diagrams Use Case Diagrams Diagramas de Casos de Uso State Diagrams Use Case Diagrams Diagramas de Objetos Diagramas de Secuencia Scenario Diagrams State Diagrams Scenario Diagrams State Diagrams Diagramas de Colaboración Diagramas de Componentes Modelo Scenario Diagrams Component Diagrams Scenario Diagrams Component Diagrams Diagramas de Estados Diagramas de Distribución Diagramas de Actividad

Diagramas de UML Diagrama de Casos de Uso Diagrama de Clases Diagrama de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interacción Diagrama de Secuencia Diagrama de Colaboración Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue El Diagrama de Objetos en realidad no se provee como un tipo de diagrama separado. En Diagramas de Secuencia, Diagramas de Colaboración y en Diagramas de Actividad se modelan objetos. He visto en algunos libros referirse a Diagramas de Paquetes, Diagramas de Subsistemas y Diagramas de Modelos. Sin embargo, éstos corresponden a casos particulares de los diagramas arriba mencionados, cuando en éstos sólo se incluye paquetes (o subsistemas, o modelos, respectivamente).

Diagramas de caso de uso Nombre de caso de uso Actor Relación o Flujo de información

Diagramas de Clases Nombre de la clase Atributos Nombre de la clase Actividades Relación

Diagramas de Estados Nombre del estado Punto inicial de un estado Punto Final de un estado Relación o Flujo de información

Diagramas de secuencia :Nombre Nombre del objeto Línea de vida de un objeto Mensaje simple Mensaje síncrono Mensaje asíncrono Activación

Diagramas de colaboracón :Nombre Nombre del objeto Relación entre Objetos Flujo de envío de mensaje

Diagramas de Actividades Punto inicial Punto Final Flujo de información Envío de indicación Recepción de indicación Decisión

Diagramas de Componentes Relación Relación entre componentes e interfaz Clases Nombre Interfaz Información Interfaz

Diagramas de Distribución Nodo Nodo con información Relación Mensaje

1 Proceso orientado a objetos consta de 3 fases de alto nivel. Planificación y Especificación de Requisitos: 1. Definir el Plan-Borrador. 2. Crear el Informe de Investigación Preliminar. 3. Definir los Requisitos. 4. Registrar Términos en el Glosario. (continuado en posteriores fases) 5. Implementar un Prototipo. (opcional) 6. Definir Casos de Uso (de alto nivel y esenciales). 7. Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) 8. Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) 9. Refinar el Plan.

2 Proceso orientado a objetos consta de 3 fases de alto nivel. Construcción del sistema. - Diseño de Alto Nivel: Se aborda el problema viendo al sistema a construir como una caja negra, centrándonos en la visión que desde el exterior tienen los actores, esto es, en los casos de uso. Se analiza el problema construyendo un modelo conceptual. - Diseño de Bajo Nivel: El sistema definido en la fase anterior se especifica en detalle, describiendo todas las operaciones que el sistema va a tener que realizar internamente para satisfacer lo especificado en el diseño de alto nivel. - Implementación: Se lleva lo especificado en el diseño a un lenguaje de programación. - Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificación y Especificación de Requisitos.

La puesta en marcha del sistema en el entorno previsto de uso. 3 Proceso orientado a objetos consta de 3 fases de alto nivel. Instalación La puesta en marcha del sistema en el entorno previsto de uso.

La fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque evolutivo, tomando en cada iteración un subconjunto de los requisitos (agrupados según casos de uso) y llevándolo a través del diseño de alto y bajo nivel hasta la implementación y pruebas. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximación se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente.