Relación con otras asignaturas del plan de estudio

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

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

3. Temario

4. Temario

5. Unidad 1.Conceptos Introductorios fdf1.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 .

6. 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 Físicos Modelos Lógicos

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

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

9. 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. 1.2 Desarrollo orientado a objetos

10. 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á?

11. 1.3Diagramación ¿Qué es UML? UML (UnifiedModelingLanguage) 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.

12. 1.3Diagramació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.

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

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

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

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

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

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

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

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

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

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

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

24. 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 funcionacorrectamente y que satisface lo especificado en la etapa de Planificación y Especificación de Requisitos.

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

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