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

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

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

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

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

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

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

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

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

Diagrama de clase adicional Dr. Juan José Aranda Aboy

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

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

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

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

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

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

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

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

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

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

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

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

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

Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy

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

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

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

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

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

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

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