La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Aspectos Avanzados de la Tecnología de Objetos

Presentaciones similares


Presentación del tema: "Aspectos Avanzados de la Tecnología de Objetos"— Transcripción de la presentación:

1 Aspectos Avanzados de la Tecnología de Objetos
2. Fundamentos del modelo de objetos Resumen de diagramas UML Dr. Juan José Aranda Aboy

2 Íconos de los diagramas de Casos de Uso
Dr. Juan José Aranda Aboy

3 Dr. Juan José Aranda Aboy
Notación Dr. Juan José Aranda Aboy

4 Dr. Juan José Aranda Aboy
Ejemplo: Simulación Dr. Juan José Aranda Aboy

5 Ejemplo: Punto de venta
Dr. Juan José Aranda Aboy

6 Íconos de los diagramas de clases
Dr. Juan José Aranda Aboy

7 Notación de los diagramas de clases
Dr. Juan José Aranda Aboy

8 Diagrama de clases y relaciones
Dr. Juan José Aranda Aboy

9 Especificaciones en diagrama de clases
Dr. Juan José Aranda Aboy

10 Diagrama de clase adicional
Dr. Juan José Aranda Aboy

11 Íconos y Notación del diagrama de estados
Dr. Juan José Aranda Aboy

12 Ejemplo: Transición de estados de la clase Historia Clínica
Dr. Juan José Aranda Aboy

13 Ejemplo: Seleccionar y manipular producto
Dr. Juan José Aranda Aboy

14 Dr. Juan José Aranda Aboy
Diagrama de actividad Dr. Juan José Aranda Aboy

15 Diagramas de interacción
Tipos de mensajes utilizados en los diagramas de colaboración y secuencia: Dr. Juan José Aranda Aboy

16 Íconos y notación de los diagramas de colaboración
Dr. Juan José Aranda Aboy

17 Diagrama de colaboración
Dr. Juan José Aranda Aboy

18 Íconos y notación de los diagramas de secuencia
Dr. Juan José Aranda Aboy

19 Dr. Juan José Aranda Aboy
Diagrama de Secuencia Dr. Juan José Aranda Aboy

20 Dr. Juan José Aranda Aboy
Diagrama de secuencia Dr. Juan José Aranda Aboy

21 Ejemplo de clase, colaboración y secuencia: Cruce regulado
Dr. Juan José Aranda Aboy

22 Interfaces, patrones y paquetes
Dr. Juan José Aranda Aboy

23 Diagramas de implementación
Dr. Juan José Aranda Aboy

24 Dr. Juan José Aranda Aboy

25 Dr. Juan José Aranda Aboy

26 Proceso y establecimiento del contexto
Dr. Juan José Aranda Aboy

27 Dr. Juan José Aranda Aboy
Referencias Amescua,A. et al “Análisis y Diseño Estructurado y Orientado a Objetos de Sistemas Informáticos” Ed. McGrawHill, 2003 Larman, C. “UML y Patrones” 2da edición. Pearson Prentice Hall, 2004 Stevens, P. y Pooley, R. “Utilización de UML en Ingeniería del Software con Objetos y Componentes”, Addison Wesley, 2002 Dr. Juan José Aranda Aboy

28 Resumen práctico del proceso
Modelado Resumen práctico del proceso Dr. Juan José Aranda Aboy

29 Dr. Juan José Aranda Aboy
Resumen (1) Capturar un Modelo del Proceso de Negocio. Éste se usará para definir las actividades y procesos de alto nivel que ocurren en una organización y proveen una base para el modelo de Casos de Uso. El Modelo del Proceso de Negocios normalmente capturará más de lo que implementaría un sistema de software, es decir, este incluye procesos manuales y otros. Trazar un Modelo de Casos de Uso al Modelo del Proceso de Negocio para definir exactamente que funcionalidad intenta proveerse desde la perspectiva del usuario de negocios. Mientras cada Caso de Uso se agrega, crea un vínculo trazable desde los procesos de negocios apropiados al Caso de Uso, es decir, una conexión de realización. Este trazado claramente establece que funcionalidad proveerá el nuevo sistema para cumplir con los requisitos del negocio establecido en el modelo del proceso. Este también asegura que no existe ningún Caso de Uso sin un propósito. Refinar los Casos de Uso. Incluye requisitos, restricciones, clasificación de complejidad, notas y escenarios. Esta información ambiguamente describe lo que hace el Caso de Uso, como se ejecuta y las restricciones en esta ejecución. Se asegura de que el Caso de Uso todavía reúne los requisitos del proceso de negocio. Incluye la definición de las pruebas del sistema para cada Caso de Uso para definir así el criterio de aceptación para cada Caso de Uso. También incluye algunos scripts de pruebas de aceptación del usuario para definir como el usuario probará esta funcionalidad y cuales son los criterios de aceptación. Dr. Juan José Aranda Aboy

30 Dr. Juan José Aranda Aboy
Resumen (2) Desde las entradas y las salidas del Modelo del Proceso de Negocio y los detalles de los casos de uso, se comienza a estructurar un modelo de dominio (objetos de negocio de alto nivel), diagrama de secuencia, diagrama de colaboración y los modelos de la interfaz de usuario. Estos describen las “cosas” en el nuevo sistema, la manera en que esas partes interactúan y la interfaz que un usuario usará para ejecutar los escenarios de los casos de uso. Desde el modelo de dominio, el modelo de la interfaz de usuario y los diagramas del escenario crean el Modelo de Clase. Esta es una especificación precisa de los objetos en el sistema, sus datos o atributos y su comportamiento u operaciones. Los objetos del dominio se pueden abstraer en las jerarquías de la clase usando herencias. Los mensajes del diagrama del escenario normalmente trazarán las operaciones de la clase. Si se usa un marco existente o patrón del diseño, es posible importar elementos del modelo existentes para usarlos en el nuevo sistema. Para cada clase define pruebas de unidad y pruebas de integración para probar completamente i) que la clase funciona como se especifican internamente y que ii) la clase interactúe con otras clases relacionadas y los componentes como se espera. Mientras la clase del modelo se desarrolla, se puede fraccionar en paquetes y componentes discretos. Un componente representa una porción despegable del software que recolecta el comportamiento y datos de una o más clases, y expone una interfaz estricta a otros consumidores de sus servicios. Así un Modelo del Componente se compila para definir el empaquetamiento lógico de las clases. Para cada componente define pruebas de integración para confirmar que la interfaz del componente reúne la especificación dada en relación con otros elementos del software. Dr. Juan José Aranda Aboy

31 Dr. Juan José Aranda Aboy
Resumen (3) Concurrentemente con el trabajo que ya realizó, se deberían capturar y documentar requisitos adicionales. Por ejemplo – los requisitos funcionales, requisitos de desempeño, requisitos de seguridad, responsabilidades, liberar planos y más. Colecta estos dentro del modelo y los mantiene al día mientras madura el modelo. El Modelo de Despliegue define la arquitectura física del sistema. Este trabajo puede comenzar tempranamente para capturar las características de despliegue físico – que hardware, sistemas operativos, capacidades de la red, software de interfaces y soporte conformarán el nuevo sistema, donde se desplegará y que parámetros aplica para recuperarse de los desastres, confiabilidad, copias de seguridad y soporte. Mientras el modelo se desarrolla la arquitectura física se actualizará para reflejar el sistema actual propuesto. Construcción del sistema: Toma piezas discretas del modelo y asigna uno o más desarrolladores. En una compilación dirigida por Casos de Uso. Esto significará asignar un Caso de Uso a un equipo de desarrollo, y hacer que ellos construyan pantallas, objetos de negocio, tablas de base de datos y los componentes relacionados necesarios para ejecutar ese Caso de Uso. Mientras cada Caso de Uso se construye, éste debería estar acompañado por pruebas de sistema, integración y unidad completas. Una construcción dirigida del componente puede ver componentes del software discretos asignados a los equipos de desarrollo para su construcción. Dr. Juan José Aranda Aboy

32 Dr. Juan José Aranda Aboy
Resumen (4) Rastrear los defectos que emergen en la fase de pruebas contra los elementos del modelo relacionados. Por ejemplo: Defectos de prueba del sistema contra los Casos de Uso, defectos de prueba de unidad contra las clases etc. Rastrear cualquier cambio contra los elementos del modelo relacionado para administrar los cambios no controlados en el alcance del proyecto: “scope creep”. Actualizar y refinar el modelo mientras se procede el trabajo – siempre evaluando el impacto de cambios y mejoras del modelo en trabajos posteriores. Usar una aproximación iterativa para trabajar a través del diseño en fragmentos discretos, siempre evaluando la compilación actual, los requisitos posteriores y cualquier descubrimiento que aparece durante el desarrollo. Entrega del software completo a un proceso de prueba y al entorno de producción. Si se realiza una entrega en fases, luego ésta migración del software de construcción desde la prueba a la producción puede ocurrir varias veces en la vida del producto. Dr. Juan José Aranda Aboy


Descargar ppt "Aspectos Avanzados de la Tecnología de Objetos"

Presentaciones similares


Anuncios Google