Relacin con otras asignaturas del plan de estudio

7/12/12

Anteriores Planificacin y modelado Redes de computadoras Tpicos selectos de programacin interfaces. Desarrollo sustentable

Posteriores

7/12/12

Objetivo(s) general(es) del curso

El estudiante disear y construir un proyecto de software conforme a los requerimientos establecidos en el dominio del proyecto de software.

Temario
Unidad 1 Tema Conceptos introductorios Diseo orientado a objetos Subtemas 1.1 La arquitectura de 4+1 vistas. 1.2 Desarrollo orientado a objetos 1.3 Diagramacin 2.1 Diseo del sistema en base a procesos 2.1.1 Actividades y casos de uso. 2.1.2 Interfaces de usuario 2.2 Diseo de la lgica 2.2.1 Clases y objetos 2.2.2 Interaccin 2.2.3 Estados y transiciones 2

7/12/12

Construccin 3 3.1 Despliegue de componentes y arquitectnico 3.2 Tcnicas 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 alimentacin. 3.2.3 Arquitectura de referencia para sistemas mviles con conexin a internet 3.2.4 Arquitectura de referencia para sistemas de informacin. 3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje 3.2.6 Arquitecturas de referencia para lneas de productos.

Temario
Unidad
4

Tema

Subtemas

7/12/12

Pruebas de Software 4.1 Definiciones 4.1.1 Prueba, caso de prueba defecto, falla error, verificacin, validacin 4.1.2 Relacin entre defecto-falla-error 4.1.3 Pruebas estructurales, funcionales y aleatorias 4.1.4 Documentacin del diseo de las pruebas 4.2 Proceso de pruebas Modelos de proceso 4.2.1 Generar un plan de pruebas de 4.2.2 Disear pruebas especificas software. 4.2.3 Tomar configuracin del software a probar 4.2.4 Configurar las pruebas 4.2.5 Evaluar resultados 4.2.5.1 Depuracin 4.2.5.2 Anlisis de errores 4.3 Tcnicas de diseo de casos de pruebas 4.4 Enfoque prctica recomendado para el diseo de casos 4.5 Estrategias de aplicacin de la pruebas 4.5.1 De unidad 4.5.2 De integracin 4.5.3 Del sistema 4.5.4 De aceptacin 5.1 Implantacin e integracin de casos de uso y componentes de software 5.2 mantenimiento del software.

5 Implantacin y mantenimiento

Unidad 1.Conceptos Introductorios

fdf

1.1 La arquitectura de 4+1 vistas

7/12/12
La arquitectura software trata el diseo e implementacin de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos para satisfacer la funcionalidad y ejecucin 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 slo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y caractersticas de la arquitectura en mltiples vistas. Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva (Kruchten, 1995). El modelo ms aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1 .

Clases Datos

Requisitos Casos de Uso Escenario s

Componen 7/12/12 tes Vista de Implementacin

Vista Estructural (Lgica)

Vista de Casos de Uso

Vista de Procesos (Dinmica) Interaccin (Colaboracin y secuencia) ActividadesModelos

Vista de Despliegue Despliegue Modelos

Vista estructural. Es todo lo que rodea 7/12/12 al sistema en desarrollo, es decir las clases; por ejemplo personas, cuentas, personal, material, etc, <<Una clase es una categora o grupo de cosas que
tienen atributos y acciones similares>>. Vista de Casos de Uso.- Es una descripcin de las acciones de un sistema desde el punto de vista del usuario, es una tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. La finalidad de este es crear una visin por publico en general y no por expertos en computacin. 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 Implementacin.- Los diagramas de componentes 7/12/12 ilustran las organizaciones y las dependencias entre los componentes de software. Un componente debe de ser Cdigo fuente componente Componentes en tiempo de ejecucin Componente ejecutable Vista de despligue.- El diagrama de despliegue o emplazamiento muestra la configuracin de los elementos de proceso en tiempo de ejecucin y los procesos de software que habitan en el. El diagrama de despliegue visualiza la distribucin de componentes a travs de la empresa.

1.2 Desarrollo orientado a objetos

7/12/12

El anlisis orientado a objetos es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y los objetos que se encuentran en el vocabulario del dominio del problema. El diseo a objetos es un mtodo de diseo que abarca el proceso de descomposicin orientada a objetos y una notacin para describir los modelos lgicos y fsicos, as como los modelos esttico y dinmico del sistema que se disea.

Cuestiones para iniciar la construccin de un proceso de sw 7/12/12

Qu es lo que va a construir?

Cmo lo va a construir?

Qu tecnologa usar?

Cmo lo documentar?

1.3 Diagramacin
7/12/12

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 solucin al problema planteado.

1.3 Diagramacin
7/12/12

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 interpretacin 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
Use Use Diagra Case Case Diagra mas Diagra ms de ms Casos de Uso State State Diagra Diagra Diagra ms mas ms de Clases

7/12/12

Los diagramas expresan grficamente partes de un modelo

Use Use Diagra Case Case Diagra mas Diagra ms de ms Secuen Scenari cia Scenari o Diagra o Diagra mas Diagra ms de ms Colabor Scenari acin Scenari o Diagra o Diagra mas Diagra ms de ms Estados State State Diagra Diagra Diagra ms mas ms de Objetos State State Diagra Diagra Diagra ms mas ms de Compon Compone Compone ente nt Diagra nt Diagrams s Diagrams mas de Distribu cin

Mode lo Diagra mas de Activida

Diagramas de UML

7/12/12

Diagrama de Casos de Uso Diagrama de Clases Diagrama de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interaccin Diagrama de Secuencia Diagrama de Colaboracin Diagramas de implementacin Diagrama de Componentes Diagrama de Despliegue

Diagramas de caso de uso

Nombre de caso de uso

7/12/12

Actor

Relacin o Flujo de informacin

Diagramas de Clases
Nombre de la clase Atributos Actividades

7/12/12

Nombre de la clase

Relacin

Diagramas de Estados
Nombre del estado Punto inicial de un estado Punto Final de un estado Relacin o Flujo de informacin

7/12/12

Diagramas de secuencia
:Nombre Nombre del objeto Lnea de vida de un objeto Mensaje simple Mensaje sncrono Mensaje asncrono Activacin

7/12/12

Diagramas de colaboracn
:Nombre Nombre del objeto

7/12/12

Relacin entre Objetos Flujo de envo de mensaje

Diagramas de Actividades
Actividad Punto inicial Punto Final Flujo de informacin Envo de indicacin

7/12/12

Recepcin de indicacin Decisin

Diagramas de Componentes7/12/12
Componente

Relacin Relacin entre componentes e interfaz Clases Nombre Interfaz Informacin Interfaz

Diagramas de Distribucin
Nodo

7/12/12

Nodo con informacin Relacin Mensaje

Proceso orientado a objetos 7/12/12 consta de 3 fases de alto nivel.

Planificacin y Especificacin de Requisitos:
1. Definir el Plan-Borrador. 2. Crear el Informe de Investigacin Preliminar. 3. Definir los Requisitos. 4. Registrar Trminos 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.

Proceso orientado a objetos 7/12/12 consta de 3 fases de alto nivel.

Construccin del sistema. - Diseo de Alto Nivel: Se aborda el problema viendo al sistema a construir como una caja negra, centrndonos en la visin que desde el exterior tienen los actores, esto es, en los casos de uso. Se analiza el problema construyendo un modelo conceptual. - Diseo 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 diseo de alto nivel. - Implementacin: Se lleva lo especificado en el diseo a un lenguaje de programacin. - 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 Planificacin y Especificacin de Requisitos.

Proceso orientado a objetos 7/12/12 consta de 3 fases de alto nivel.

Instalacin

La puesta en marcha del sistema en el entorno previsto de uso.

7/12/12

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 iteracin un subconjunto de los requisitos (agrupados segn casos de uso) y llevndolo a travs del diseo de alto y bajo nivel hasta la implementacin y pruebas. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximacin 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.

7/12/12