Unidad III.- Paradigmas de la Ingeniería de Software.

o El enfoque estructuradoo El enfoque orientado a objetos.

Competencias Genéricas a desarrollar en la unidad• Capacidad crítica y autocrítica• Solución de problemas• Capacidad de aplicar los conocimientos• Habilidad para buscar y analizar información proveniente de fuentes diversas.

Criterios de evaluación de la Unidad (Conceptuales, Procedimentales y Actitudinales)

Conceptuales: 50%Procedimentales: 40%Actitudinales: 10%

Unidad III.- Paradigmas de la Ingeniería de Software.

La Ingeniería de Software está compuesta por una serie de pasos que abarcan los métodos, herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniería de Software.

o El enfoque estructurado

El análisis estructurado es el método más usado para el modelado de requisitos, utiliza el modelo de datos y el modelo de flujos para crear la base de un adecuado modelo de análisis.

Los sistemas de datos y flujos de control son la base de representación de la trasformación de datos y control. Al mismo tiempo, estos métodos son usados para crear un modelo funcional del software y proveerse de un mecanismo para dividir funciones.

En el análisis estructurado la palabra estructura significa qué:

•El método intenta dar forma al proceso de determinación de los requerimientos comenzando con la documentación del sistema existente; •el proceso está organizado de tal forma que intenta incluir todos los detalles relevante que describe al sistema en uso; •es fácil verificar cuando se han omitido detalles relevantes; •la identificación de los requerimientos será similar entre varios analistas e incluirá las mejora soluciones y estrategias para las oportunidades de desarrollo de sistemas; y •los documentos de trabajo generados para documentar los sistemas existente o propuesto son dispositivos de comunicación eficientes.

Características del análisis estructurado.

Símbolos gráficos; iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. Diccionario de datos; descripciones de todos los datos utilizados en el sistema. Descripciones de procesos y procedimientos; declaraciones formales que emplean técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas; estándares para describir y documentar el sistema en forma correcta y completa. 

Especificación formal de datos

 

1. Diagrama de Flujos de datos:

Los diagramas de flujos de datos son una técnica de análisis estructurado que van de lo general a lo específico muestran las posibles entradas, procesos y salidas del sistema. Los diagramas son usados cuando los analistas tratan de comprender los requerimientos de información de los usuarios de una manera gráfica utilizando solo cuatro símbolos combinados entre sí.

Los componentes de un diagrama típico de flujo de

datos:

•Proceso.

•Flujo.

•Almacén.

•Entidad o Terminador

ProcesoEl primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja, función, transformación. El proceso muestra una parte del sistema que transforma entradas en salidas. El proceso se representa gráficamente como un círculo, como se muestra en figura .

Calcular impuest

o de venta

Otras notaciones de proceso

Algunos analistas prefieren usar un óvalo o un rectángulo con esquinas redondeadas.

1Calcular Impuesto De ventas

Las diferencias entre estas tres formas son puramente cosméticas, aunque obviamente es importante usar la misma forma de manera consistente para representar todas las funciones de un sistema.

Flujo

Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo se muestra en la figura. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Pregunta de un cliente

…Flujo

En la mayoría de los sistemas que modele como analista, los flujos realmente representan datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos tipos de información con los que las computadoras pueden tratar.Nótese que el flujo de la figura tiene nombre. El nombre representa el significado del paquete que se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo indica su nombre.

AlmacénEl almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas, como lo muestra la figura. De modo característico el nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos.

…Almacén

Para el analista con conocimiento de proceso de datos es tentador referirse a los almacenes como archivos o base de datos; pero un almacén también pudiera consistir en datos almacenados en tarjetas perforadas, microfilm, microfichas, discos ópticos, etc. y un almacén también puede ser un conjunto de fichas de papel en una caja de cartón, nombres y domicilios en un directorio, diversos archivos en un archivero, o varias formas no computarizadas.

Entidad o terminador

El terminador gráficamente se representa como un rectángulo, como se muestra en la figura. Los terminadores representan entidades externas con las cuales el sistema se comunica.

DEPARTAMENTO DE VENTAS

…Entidad o terminador

Comúnmente, puede ser una persona, o un grupo, por ejemplo, una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste.

Diagrama de Contexto

El diagrama de contexto debe mostrar un panorama global que incluya las entradas básicas, el sistema general y las salidas. Este diagrama será el más general , con una visión muy superficial del movimiento de los datos en el sistema y una visualización lo más amplia posible del sistema.

Al proceso se le asigna el número cero. En el diagrama de contexto se muestran todas las entidades externas, así como también los flujos de datos principales que van desde y hacia dichas entidades. El diagrama no contiene ningún almacén de datos.

Procedimiento paso a paso para hacer un Diagrama de

Contexto1. Piense en el sistema que está analizando

como si fuera un recipiente, para diferenciar su interior del exterior.

2. Ignore las tareas puramente internas del recipiente; aplicando así el concepto de caja negra.

3. Pregunte a sus usuarios finales cuales son los sucesos o transacciones a los cuales debe responder el sistema. Por ejem: Pedidos, Reclamos, Pagos, etc.

4. Para cada suceso, pregunte cuáles son las respuestas que debería generar el sistema. Por ejemplo: Pedido - Programar pedido

Reclamo - Dar respuesta Pago - Elaborar recibo

5. Pregunte cuales son los informes de formato fijo que debe producir el sistema .

6. Identifique las fuentes netas de datos para cada suceso o transacción. Estas fuentes se convertirán en los agentes internos o externos del sistema.

7. Identifique los recipientes netos de cada respuesta o salida que debería generar el sistema. Estos destinos serán también agentes internos o externos.

…Procedimiento paso a paso para hacer un Diagrama de Contexto

…Procedimiento pasa a paso para hacer un Diagrama de Contexto

8. Identifique todos los posibles almacenes de datos externos.

9. Dibuje un diagrama de contexto para toda la información anterior.

Ejemplo de diagrama de contexto

Otro ejemplo de un diagrama de contexto o cero

Ejemplo de diagramas padre

Ejemplo de diagrama hijo

2. -Diccionario de datos

Se ha propuesto como la gramática casi formal para describir el contenido de los objetos definido durante el análisis. El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista de sistemas tengan una misma comprensión de las entradas, salidas, de los componentes de los almacenes y [también] de los cálculos intermedios.

…Diccionario de datos

El diccionario de datos guarda y organiza los detalles del Diagrama de Flujo de Datos (DFD). Es el segundo componente del análisis estructurado. También se conoce como "Data Repository". Incluye el contenido de los data flow (flujos de datos), los "data store", las entidades externas y los procesos.

El diccionario de datos se podría usar para:

1. Validar la integridad y exactitud del DFD2. Proporcionar un punto de partida para

desarrollar pantallas e informes.3. Determinar el contenido de los datos

almacenados en archivos.4. Desarrollar la lógica para los procesos del

diagrama de flujo de datos.

Definición de los flujos de datos

La información capturada para cada flujo de datos se podría resumir usando un formulario que contenga la siguiente información:

1. ID, un número de identificación opcional.2. Un solo nombre descriptivo para este Flujo de datos.3. Un descripción general del flujo de datos.4. La fuente del flujo de datos. 5. El destino del flujo de datos.6. Algo que indique si el flujo es un registro que está

entrando o saliendo de un archivo o un registro que contiene un informe, formulario o pantalla.

7. El nombre de la estructura de datos que describe los elementos encontrados en este flujo de datos.

8. El volumen por unidad de tiempo.9. Un área para comentarios adicionales.

Descripción de las estructuras de datos

Estas se describen usando una notación algebraica, que usa los siguientes símbolos:

1. Un signo (=) significa “esta compuesto de”2. Un signo de suma (+) significa “y”3. Las llaves { } indican elementos repetitivos,

también llamados grupos de repetición o tablas. 4.Los corchetes [ ] representan una situación de uno u otro. Se podría representar un elemento u otro, pero no ambos.5. Los paréntesis ( ) representan un elemento opcional. Los elementos opcionales se podrían dejar en blanco en la entrada de las pantallas y podrían contener espacios o ceros para campos numéricos en las estructuras de archivos.

Ejemplo de diccionario datos

Pedido del cliente= número de cliente + nombre del cliente + dirección+ telefono+ numero de catalago+ fecha de pedido.

nombre del cliente= nombre + (inicial del segundo nombre)+ apellido.

3. Especificaciones de procesos

Las especificaciones de procesos se crean para los procesos primitivos en un diagrama de flujo de datos así como también para algunos procesos de nivel superior que se amplían a un diagrama hijo.

Estas especifican la lógica de la toma de decisiones y las fórmulas que transformarán los datos de entrada de un proceso en salidas.

Las tres metas para producir especificaciones de procesos

1. Reducir la ambigüedad del proceso. Esta meta obliga al analista aprender los detalles acerca del funcionamiento de un proceso. Es necesario detectar, anotar e integrar las áreas indefinidas de todas las especificaciones de procesos. Estas observaciones constituyen una base y proporcionan las preguntas para las entrevistas de seguimiento con la comunidad de usuarios.

2. Obtener una descripción precisa de lo que se está realizando, lo cual normalmente se incluye en un paquete de especificaciones para el programador.

3. Validar el diseño del sistema. Esta meta incluye garantizar que un proceso tenga todo el flujo de datos de entrada necesario para producir salida. Además, todas las entradas y salidas deben representarse en el DFD.

…Las tres metas para producir especificaciones de procesos

Algunas categorías que no requieren especificaciones

1. Procesos que representan entrada o salida física, tal como leer y escribir. Por lo general estos procesos sólo requieren lógica simple.

2. Procesos que representan una validación de datos simple, la cual normalmente es bastante fácil de realizar.

3. Procesos que usen código pre escrito. Estos procesos generalmente se incluyen en un sistema como subprogramas y funciones.

Formato de las especificación de procesos

1. El número del proceso, el cual debe coincidir con el ID del proceso del DFD. Estas especificaciones permiten al analista trabajar con cualquier proceso o modificarlo y localizar fácilmente el diagrama de flujo de datos donde se encuentra el proceso.

2. El nombre del proceso, el cual nuevamente debe ser el mismo que el asentado en el símbolo del proceso en el DFD.

3. Una descripción breve de lo que realiza el proceso.

…Formato de las especificación de procesos

4. Una lista de flujos de datos de entrada, usando los nombres que están en el diagrama de flujos de datos. Los nombres de datos que se usan en la fórmula o lógica deben coincidir con los diccionarios de datos.

5. Los flujos de datos salida, utilizando también los nombres del DFD y del diccionario de datos.

6. Una indicación del tipo de proceso: por lote, en línea o manual. Todos los procesos en línea requieren diseños de pantalla, y todos los procesos manuales deben tener procedimientos bien definidos bien definidos para que los empleados realicen las tareas del proceso.

7. Si el proceso usa código preescrito, incluya el nombre del subprograma o función que contenga al código.

8. Una descripción de la lógica del proceso que indique las políticas y reglas del negocio en el lenguaje cotidiano, no en pseudocódigo de lenguaje de computadoras. Las reglas del negocio son los procedimientos, o quizás un conjunto de condiciones o fórmulas, que permiten a una corporación dirigir su negocio. Los formatos comunes de las reglas del negocio incluyen lo siguiente:Definiciones de los términos del negocio.Condiciones y acciones del negocio.Restricciones de la integridad de los datos.Derivaciones matemáticas y funcionales.Inferencias lógicas.Secuencias de procesamiento.Relaciones entre las circunstancias del negocio.

9. Si no hay suficiente espacio en el formulario para una descripción completa del Español estructurado o si hay una tabla o árbol de decisión que describa la lógica , incluir el nombre de la tabla o árbol correspondiente.

10. Mencione cualquier problema sin resolver, partes incompletas de la lógica u otras consideraciones. Estos problemas constituyen la base de las preguntas usadas para entrevistas de seguimiento.

…Formato de las especificación de procesos

Formulario de especificaciones del procesoNúmero: 1.3Nombre: Determinar cantidad disponibleDescripción: Determinar si un artículo está disponible para la venta. Si no está disponible, crear un registro de artículo por reabastecer. Determinar la cantidad disponible.

Flujo de datos de entradaArtículo válido del proceso 1.2 Cantidad disponible según el Registro del artículo

Flujo de datos de salidaArtículo disponible (Número del artículo + Cantidad vendida) para los procesos 1.4 y 1.5Artículo por reabastecer para el control de inventario.

Tipo de proceso: En línea Por lote Manual

Nombre de subprograma/Función

Tipo de proceso:IF Cantidad pedida del artículo es mayor que la Cantidad disponible THEN Mueva la Cantidad pedida del artículo a la Cantidad disponible del artículo Mueva el Número del artículo pedido al Número del artículo disponible ELSE Reste la Cantidad disponible de la Cantidad pedida del artículo para obtener la Cantidad por reabastecer Mueva la Cantidad por reabastecer al Registro del artículo por reabastecer Mueva el Número del artículo al Registro del artículo por reabastecer DO Registro por reabastecer Mueva la Cantidad disponible a la Cantidad del artículo disponible Mueva Número del artículo pedido al Número del artículo disponible ENDIF

Consulte : Nombre:________________________________________________________

Español estructurado Tabla de decisión Árbol de decisión

Asunto sin resolver:

¿se debe tomar en cuenta la cantidad del pedido para este artículo?¿Esto podría, combinado con la flecha esperada de llegada de los artículos del pedido, cambiar la forma en que se calcula la cantidad disponible?

El enfoque orientado a objetos.

Fundamentos de lo Orientado a Objetos

El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.

Fundamentos de lo Orientado a Objetos

La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulación. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes. Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.

Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.

Concurrencia . Es la propiedad que distingue un objeto que está activo de uno que no lo está.

Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).

Según [Booch 1986], los beneficios del enfoque OO son:Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, [ y recientemente Java] . Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseños completos. Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología.

El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad.Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su única función es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada.

[Greiff 1994] comenta que el Análisis Orientado a Objetos (OOA por sus siglas en inglés de Object Oriented Analysis) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema".

Según [Booch 1986], el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos lógico y físico tal como los modelos estáticos y dinámicos del sistema bajo diseño“.

En cuanto a las metodologías OO, diremos que hay un gran número de métodos orientado a objetos actualmente. Muchos de los métodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. Algunos de las metodología más conocidas y estudiadas hasta antes del UML según [Jacobson 1992] son: Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.

Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en lo que se es el UML.

Lenguaje Unificado de modelado (UML)

El Lenguaje Unificado de Modelado pre escribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan.

Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real.

UML ofrece nueve diagramas en los cuales modelar sistemas.

• Diagramas de Casos de Uso para modelar los procesos ’business’.• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.• Diagramas de Colaboración para modelar interacciones entre objetos.• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.• Diagramas de Componentes para modelar componentes.• Diagramas de Implementación para modelar la distribución del sistema.

Casos de uso

Imagínese como una colección de situaciones respecto al uso de un sistema.

Cada escenario describe una secuencia de eventos.

Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo.

A las entidades que inician secuencias se les conoce como actores.

Símbolos del caso de uso

Tipos de relaciones

``Comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.

``usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.

``extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro.

Ejemplo de Extensión (Asociación)

Ejemplo de Inclusión (Asociación)

Documentación de los casos de usos

•Un documento de flujo de eventos es creado por cada uno de los casos de uso.•Escrito desde el punto de vista del actor.•Detalla de que proveerá el sistema al actor cuando el caso de uso sea ejecutado.

Contenido típico:• Precondiciones : Cómo el caso de uso empieza .

• Flujo Principal o normal de eventos• Flujo alterno de eventos• Flujo excepcional de eventos

Ejemplo:

Flujos de eventos del CU “ Mantener Información de Usuarios ”1.1.- Precondiciones.El usuario al que se le asignará una contraseña debe de ser un empleado de la empresa. 1.2.-Flujo Principal. Este CU empieza cuando el administrador de la base de datos (ABD) se conecta al sistema e introduce su contraseña. El sistema verifica su contraseña (E-1) y el sistema presenta un menú de opciones, las cuales son las siguientes: Altas, Bajas, Cambios, Consultas o Salir.

Mantener información de usuario

usuarioABD

…documentación de caso de uso

Si la actividad deseada es Altas se hace el subflujo S-1 “Agregar Usuario” Si la actividad deseada es Bajas se hace el subflujo S-2 “Borrar Usuario” Si la actividad deseada es Cambios se hace el subflujo S-3 “Modificar Datos del Usuario ” Si la actividad deseada es Consultas se hace el subflujo S-4 “Consultar Usuario” Si la actividad deseada es Salir el CU termina.

1.3.- Subflujos.S-1: “ Agregar Usuario ”El sistema muestra la pantalla de usuario que contiene cuatro campos (idUsuario, nombre, contraseña, tipoUsuario). El ABD introduce los cuatro campos (E-2). El sistema muestra los nuevos datos del usuario (E-3). El CU comienza de nuevo.

1.4.- Flujos alternativos.

E-1: Si el identificador del ABD no es valido el usuario puede ingresar de nuevo o salir del sistema.

E-2: idUsuario/ nombre/ contraseña/ tipoUsuario no valido repetir o salir.

E-3: Los datos de un nuevo usuario no pueden mostrarse. Se informa al usuario que la información no esta disponible. El CU comienza.

UML - DIAGRAMA DE CLASES

Un diagrama de clases muestra la existencia de clases y sus relaciones desde el punto de vista lógico del sistema.

Los elementos de modelado del UML en un diagrama de clases son:•Clases, sus estructuras y comportamiento.•Relaciones de Asociación, agregación, dependencia y herencia.

CLASE:

Una clase es una colección de objetos que tienen una estructura, comportamiento, relaciones y semántica comunes.

Las clases son encontradas examinando a los objetos en un diagrama de secuencia y de colaboración.

Una clase es dibujada como un rectángulo con tres compartimientos.

Una clase debe de ser nombrada utilizando el vocabulario del dominio.

Deben ser creados estándares para dar nombre a las clases.

Definición de atributos.

Los atributos describen el estado del objeto. Un atributo consta de dos partes: un nombre de atributo y un valor de atributo.

Los objetos simples pueden constar de tipos primitivos, tales como enteros, carácter, boolean, reales, o tipos simples definidos por el usuario. Los objetos complejos pueden constar de pilas, conjuntos, listas array, etc., o incluso estructuras recursivas de alguno o todos los elementos. Ejemplo:

Automóvil

marcamodelocolor

Celular

MarcamodeloPrecio

Alumno

nombredirecciónteléfono

Definición de servicios.Los métodos (operaciones o servicios) describen el comportamiento asociado a un objeto. La ejecución de un método puede conducir a cambiar el estado del objeto o dato local del objeto.Cada método tiene un nombre y un cuerpo que realiza la acción o comportamiento asociado con el nombre del método. Ejem:Automóvil

marcamodelocolor

acelerar()frenar()reversa()

Celularmarcamodelo

llamar()colgar()recibirMensaje()enviarMensaje()

Alumnonombredirecciónteléfono

reinscripción()imprimirBoleta()bajaTemporal()bajaDefinitiva()

Diagrama de Colaboración

Modela la interacción entre los objetos de un Caso de Uso.

Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección.

Ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema.

Ejemplo: Diagrama de colaboración de usuario

:Pantalla de Usuario

insertar ( contraseña, seleccion)

:sistema

1: agregar(contraseña, seleccion)

[contraseña= T 2.1: enviar(seleccion)

[ contraseña=F ] 2.2: Salir

:datosUsuario

:Usuario3: verificar(seleccion)

4.1:crearUsuario() 4.2:borrarUsuario()

4.3::modificarDatosUsuario() 4.4:consultarDatosUsuario()

5: Salir