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 objetos1.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 usuario2.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ónico3.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

4

4

5

Pruebas de Software

Modelos de proceso desoftware.

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 pruebas4.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 errores4.3 Técnicas de diseño de casos de pruebas4.4 Enfoque práctica recomendado para el diseño de casos4.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 software5.2 mantenimiento del software.

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 Estructural(Lógica)

Vista de Implementación

Vista de Procesos(Dinámica)

Vista de Despliegue

Vista de Casos de Uso

•Clases •Datos

Componentes

Despliegue

Modelos Físicos

•Interacción (Colaboración y secuencia)•Actividades•Estados

Modelos Lógicos

•Casos de Uso•Escenarios

Requisitos

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 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.

¿Qué es lo que va a construir?

¿Cómo lo va a construir?

¿Qué tecnología usará?

¿Cómo lo documentará?

Cuestiones para iniciar la construcción de un proceso de sw

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

Use CaseDiagramsUse Case

DiagramsDiagramas de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribución

StateDiagramsState

DiagramsDiagramas de Objetos

ScenarioDiagramsScenario

DiagramsDiagramas deEstados

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

Diagramas deActividad

Modelo

Los diagramas expresan gráficamente partes de un modelo

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

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

Relación

Nombre de la clase

Atributos

Actividades

Diagramas de Estados

Nombre del estado

Punto inicial de un estado

Relación o Flujo de información

Punto Final de un estado

Diagramas de secuencia

Nombre del objeto

Línea de vida de un objeto

Mensaje síncrono

:Nombre

Mensaje simple

Mensaje asíncrono

Activación

Diagramas de colaboracón

Nombre del objeto

Relación entre Objetos

:Nombre

Flujo de envío de mensaje

Diagramas de ActividadesActividad

Punto inicial

Flujo de información

Punto Final

Envío de indicación

Recepción de indicación

Decisión

Diagramas de Componentes

Componente

Relación entre componentes e interfaz

Relación

Clases

InterfazNombre Interfaz

Información

Diagramas de Distribución

Nodo

Relación

Nodo con información

Mensaje

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.

Proceso orientado a objetos consta de 3 fases de alto nivel.

1

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.

Proceso orientado a objetos consta de 3 fases de alto nivel.

2

Instalación

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

Proceso orientado a objetos consta de 3 fases de alto nivel.

3

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.