La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

UML José Vargas Mery. Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un sistema –Casos de Uso –Estructura –Estado –Comportamiento.

Presentaciones similares


Presentación del tema: "UML José Vargas Mery. Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un sistema –Casos de Uso –Estructura –Estado –Comportamiento."— Transcripción de la presentación:

1 UML José Vargas Mery

2 Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un sistema –Casos de Uso –Estructura –Estado –Comportamiento –Implementación

3 Diagramas UML Diagramas de Casos de Uso Diagramas de Clases Diagramas de Objetos Diagramas de Colaboración Diagramas de Secuencia Diagramas de Estados Diagramas de Actividades Diagramas de Despliegue Diagramas de Componentes Modelo del Sistema

4 Diagramas UML Casos de Uso –Diagramas de Casos de Uso Estructura –Diagramas de Clases –Diagramas de Objetos Estado –Diagramas de Estados –Diagramas de Actividades Comportamiento –Diagramas de Secuencia –Diagramas de Colaboración Implementación –Diagramas de Componentes –Diagramas de Despliegue

5 Actividades Generales del análisis Orientado Objeto 1. Modelar las funciones del sistema. 2. Encontrar e identificar los objetos del negocio. 3. Organizar los objetos e identificar sus relaciones. 4. Modelar el comportamiento de los objetos.

6 Modelación de Casos de Uso Modelación de las funciones de un sistema en términos de los eventos del negocio, quién los inicia, y cómo responde el sistema a ellos.

7 Caso de Uso Secuencia de pasos o actividades relacionadas por su comportamiento (un escenario), tanto automatizadas como manuales, que tienen como fin completar una única tarea del negocio. Notación en UML

8 Actor Representa cualquier cosa que necesita interactuar con el sistema para intercambiar información. Un actor es un usuario del sistema, un rol, que puede ser tanto una persona como un sistema externo. En un caso de uso, hay un actor que inicia la acción y, posiblemente, otros actores participantes. Notación en UML Cajero

9 Casos de Uso - ejemplo El siguiente caso de uso de alto nivel describe el proceso de comprar artículos en una tienda cuando se emplea una terminal en el punto de venta. Caso de uso:Comprar productos Actores:Cliente, Cajero Tipo:Primario Descripción:Un Cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los artículos comprados.

10 Cursos de Eventos Curso normal de los eventos –Describe en detalles la interacción entre los actores y el sistema. –Un aspecto esencial es que explica la secuencia más común de los eventos; no incluye situaciones alternativas. Curso alternativo de los eventos –Describe importantes opciones o excepciones que pueden presentarse en relación con el curso normal. –Si son complejas, se pueden expandir y convertir en otros casos de uso.

11 Curso Normal de Eventos Acción de los actoresRespuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja TPDV (Terminal de Punto de Ventas) con productos que desea comprar. 2. El Cajero registra la identificación de cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad. 3. Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual. 4. Al terminar de introducir los productos, el Cajero indica al TPDV que se concluyó la captura de productos. 5. Calcula y presenta el total de la venta. 6. El Cajero indica el total al Cliente.

12 Curso Normal de Eventos 7. El Cliente efectúa el pago en efectivo – el efectivo ofrecido – posiblemente mayor que el total de la venta. 8. El Cajero registra la cantidad de efectivo recibida. 9. Muestra al cliente la diferencia. Genera un recibo. 10. El Cajero deposita el efectivo recibido y extrae el cambio de pago. El Cajero le da al Cliente el cambio y el recibo impreso. 11. Registra la venta concluida. 12. El Cliente se marcha con los artículos comprados. Cursos alternativos · Línea 2: introducción del identificador inválido.Indicar error. · Línea 7: el cliente no tenía suficiente dinero.Cancelar la transacción de venta.

13 Casos de Uso – Eventos Temporales Evento temporal –Es un evento del sistema que es gatillado por el paso del tiempo. –El actor del caso de uso de un evento temporal es el tiempo.

14 Beneficios de la Modelación de Casos de Uso Base para identificar objetos y sus relaciones y responsabilidades de alto nivel. Visualizar el comportamiento del sistema desde el punto de vista de una persona externa. Herramienta eficaz para validar requisitos. Herramienta eficaz de comunicación. Base para un plan de prueba. Base para un manual de usuario.

15 Proceso de Modelación de Casos de Uso Paso 1: Identificar Actores y Casos de Uso Paso 2: Construir un Diagrama de Casos de Uso Paso 3: Documentar el Curso Normal del Caso de Uso Paso 4: Definir Caso de Uso de Análisis

16 Diagrama de Contexto – Sistema de Servicio al Cliente

17 Actor Potential Member Club Member Past Member Marketing Time Use Case Name SUBMIT NEW SUBSCRIPTION PLACE NEW MEMBER ORDER MAKE ACCOUNT INQUIRY MAKE PURCHASE INQUIRY MAINTAIN MEMBER ORDER SUBMIT CHANGE OF ADDRESS SUBMIT RESUBSCRIPTION SUBMIT NEW MEMBER SUBSCRIPTION PROGRAM SUBMIT PAST MEMBER RESUBSCRIPTION PROGRAM SUBMIT NEW PROMOTION GENERATE QUARTERLY PROMOTION ANALYSIS GENERATE QUARTERLY SALES ANALYSIS GENERATE QUARTERLY MEMBERSHIP ANALYSIS GENERATE ANNUAL SALES ANALYSIS GENERATE ANNUAL MEMBERSHIP ANALYSIS Use Case Description Potential member joins the club by subscribing. (Take anu 12 CDs for one penny and agree to buy 4 more at regular club prices within two years.) Club member places order. Club member wants to examine his or her account history. (90-day time limit) Club member inquires about his/her purchase history. (three-year time limit) Club member wants to revise an order or cancel an order. Club member changes address. (including and privacy code) Past member rejoins the club by resubscribing. Marketing establishes a new membership resubscription plan to entice new members. Marketing establishes a new membership resubscription plan to lure back former members. Marketing initiates a promotion. (Note: A promotion features specific titles, usually new, that company is trying to sell at a special price. These promotions are integrated into a catalog sent (or communicated) to all members.) Print quarterly promotion analysis report. Print annual sales analysis report. Print annual membership analysis report. Print annual sales analysis report. Print annual membership analysis report. Paso 1: Identificar Actores y Casos de Usos

18 Paso 2: Construir un Diagrama de Casos de Usos

19 Paso 3: Documentar curso normal del caso de uso

20

21 Referencia a los requerimientos con los cuales está relacionado. El curso común del evento que describe los pasos principales del caso del uso, desde cuando comienza hasta cuando termina la interacción con el actor. Cursos alternativos que describen excepciones al curso común del evento. Precondición que describe el estado en que debe estar el sistema para que se ejecute el caso del uso. Poscondición que describe el estado en que queda el sistema después de que se ejecuta el caso del uso. Supuestos, que incluye cualquier tópico no relacionado con el comportamiento del caso de uso, tales como rendimiento o seguridad, que está asociado al caso de uso. En general, son aspectos que son difíciles de modelar dentro del curso de eventos del caso de uso

22 Tipos de Casos de Usos Caso de Uso de Extensión –Amplía la funcionalidad (curso normal) de un cierto caso de uso. –Un caso de uso de extensión puede ser invocado solamente por el caso del uso que está ampliando. Caso de Uso Abstracto –Contiene los cursos normales que son comunes a dos o más casos de uso originales. –Un caso de uso abstracto reduce redundancia y promueve la reutilización.

23 Representación usando la notación de UML

24 Casos de Uso – Relaciones UML define tres tipos de relación en los Diagramas de Casos de Uso Comunicación

25 Casos de Uso – Relaciones Inclusión –Una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino > es equivalente a >

26 Casos de Uso – Relaciones Extensión –El Caso de Uso origen extiende el comportamiento del Caso de Uso destino

27 Paso 4: Definir Caso de Uso de Análisis

28

29 Actividades Generales del Análisis Orientado Objeto 1. Modelar las funciones del sistema. 2. Encontrar e identificar los objetos del negocio. 3. Organizar los objetos e identificar sus relaciones. 4. Modelar el comportamiento de los objetos.

30 Encontrar e Identificar Objetos del Negocio Paso 1: Encontrar objetos potenciales –Subrayar (o destacar) los sustantivos del caso de uso Paso 2: Seleccionar los objetos propuestos –Quitar los sustantivos que representan: Sinónimos Sustantivos fuera del alcance del sistema Sustantivos que son roles que no tienen un comportamiento único o que son externos Sustantivos confusos que necesitan ser reenfocados Sustantivos que son en realidad acciones o cualidades

31 Caso de uso con Sustantivos Subrayados

32

33 Objetos Potenciales Extraídos desde el caso de uso Análisis de Objetos Potenciales POTENTIAL OBJECT LIST Accounts Receivable Department Amount Due Club Member Credit Card Information Credit Problem Notice Credit Status File Marketing Department Member Address Member Order Member Phone Number Member Services Department Member Services System Order Order Confirmation Notice Order Sales Tax Order Status Order Subtotal Ordered Product Ordered Product Information Ordered Product Quantity Past Member Payments Potential Member Product Product Inventory Product Number Street Address Transaction Warehouse Warehouse Packing Order

34

35 Resultados del Análisis PROPOSED OBJECT LIST CLUB MEMBER MEMBER ORDER MEMBER ORDERED PRODUCT PAST MEMBER PAYMENT POTENTIAL MEMBER PRODUCT TRANSACTION AGREEMENT AUDIO TITLE MERCHANDISE GAME TITLE PROMOTION RETURN TITLE VIDEO TITLE -- PLUS --

36 Actividades Generales delAnálisis Orientado Objeto 1. Modelar las funciones del sistema. 2. Encontrar e identificar los objetos del negocio. 3. Organizar los objetos e identificar sus relaciones. 4. Modelar el comportamiento de los objetos.

37 Diagramas que muestran la estructura del sistema Diagrama de clases –Muestra las clases de objetos de las que está compuesto el sistema, así como las relaciones que existen entre ellos. Diagrama de objetos –Similar al anterior, pero muestra instancias individuales de cada clases.

38 Objetos, Atributos, e Instancias Objeto –Es algo (persona, lugar, cosa, o evento) que es visto, tocado, o percibido de alguna manera, y sobre el cual los usuarios almacenan datos y le asocian un cierto comportamiento. Atributos –Datos que representan características de interés de un objeto. Instancia –Una instancia (o instancia de un objeto) está formada por los valores para cada uno de los atributos que describen un objeto específico.

39 Objetos, Atributos, e Instancias :Customer customer number = last name =Bentley first name =Lonnie home phone = street =2625 Darwin Dr. city =West Lafayette state =Indiana zip code =47906 etc : Book ISBN = type = textbook title = Systems Analysis & Design Methods copyright = : Book ISBN = type = workbook title = Projects and Cases to Accompany SADM copyright = 1996 (a) (b)

40 Método Se entiende por comportamiento a todo aquello que el objeto pueda hacer y que corresponde a funciones que actúan sobre los datos (atributos) del objeto. En el contexto de orientación a objetos, se utiliza el concepto de método (o servicio) para referirse al comportamiento de un objeto.

41 Encapsulación Es la agrupación de varios elementos en una unidad. Los atributos y métodos se encapsulan en el objeto. La única forma de acceder a los atributos de un objeto es a través de sus métodos.

42 Clases de Objetos Es un conjunto de objetos que tienen en común los mismos atributos y el mismo comportamiento. Las clases también se denominan clases de objetos. Open() Close() ISBN type title copyright Book Customer customer number last name first name home phone street city state zip code etc. changeAddress()

43 Herencia Describe el mecanismo mediante el cual los atributos y/o métodos definidos para una clase de objetos puede ser heredado o reutilizado por otra clase de objetos. Generalización/Especialización –Es una técnica donde los atributos y métodos que son comunes a varios tipos de clases de objetos se agrupan en su propia clase, llamada supertipo. Los atributos y métodos de la clase de objetos supertipo son heredados a las clases de objetos originales.

44 Supertipos y Subtipos Clase Supertipo –Es una clase de objetos cuyas instancias almacenan atributos que son comunes a una o más clases subtipos. Clase Subtipo –Es una clase de objetos cuyas instancias heredan algunos atributos comunes de una clase supertipo, y luego agregan otros atributos que son únicos para las instancias del subtipo.

45 Supertipos y Subtipos Clase Persona (supertipo) Clase Alumno (subtipo) Clase Profesor (subtipo) Alumno AAlumno BAlumno C Profesor AProfesor B

46 Generalización/Especialización en UML walk() jump() talk() sleep() eat() etc.() last name first name birth date gender Person enroll() displayGPA() GPA classification Student lecture() rank Teacher Puntas de flechas indican relación de generalización/especialización

47 Relaciones entre clases de objetos Es una asociación natural de negocios que existe entre una o más clases de objetos. 0..* CustomerOrder Places

48 Multiplicidad Define como varias instancias de una clase de objetos puede ser asociada con una sola instancia de otra clase de objetos.

49 Notación de Multiplicidad en UML

50 Book Cover Table of Contents ChapterIndex Page Paragraph Word 11..* * 0..* 1..* Diamante sólido indica relación de agregación compuesta Ejemplo en UML de una relación de agregación compuesta

51 Team Player 0..* Diamante hueco indica una relación de agregación compartida Ejemplo en UML de una relación de agregación compartida

52 Mensaje Customer add order modify order delete order display status etc. order number order date order status etc. Order display order status of order MENSAJE SOLICITADO (contiene nombre del método solicitado y los atributos requeridos por la clase ORDER) Se pasa un mensaje cuando un objeto invoca uno o más métodos de otro objeto para requerir información o producir una acción.

53 Construcción de un Diagrama de Clases Paso 1: Identificar Asociaciones y Multiplicidad –Subrayar (o destacar) los sustantivos del caso de uso Paso 2: Identificar relaciones de Generalización /Especialización Paso 3: Identificar relaciones de Agregación Paso 4: Preparar el diagrama de Clases

54 Diagrama de Clases del Sistema de Servicio a Clientes

55 Actividades Generales del Análisis Orientado Objeto 1. Modelar las funciones del sistema. 2. Encontrar e identificar los objetos del negocio. 3. Organizar los objetos e identificar sus relaciones. 4. Modelar el comportamiento de los objetos.

56 Diagramas que describen el estado de los objetos Diagramas de Estados –Los diagramas de estados se utilizan para modelar el comportamiento dinámico de un objeto particular. –Ilustran el ciclo de vida de un objeto – los varios estados que un objeto puede asumir y los eventos que causan la transición del objeto de un estado a otro.

57 Ejemplo de Estados de un Objeto Posibles estados del Trasbordador Espacial

58 Diagrama de estados Modela el ciclo de vida de un solo objeto. Representa los diversos estados que un objeto puede tener, los eventos que hacen que el objeto cambie de estado en el tiempo, y las reglas que gobiernan la transición del objeto entre los estados. Especifica de qué estado de un objeto es posible la transición a otro estado. Los diagramas de estados no son requeridos para todos los objetos. Típicamente, un diagrama de estados se construye solamente para aquellos objetos que tienen estados claramente identificables y un comportamiento complejo.

59 Diagrama de estados – teléfono Ocioso Activo descolgar auricular colgar auricular Estado inicial Transición Evento

60 Diagrama de estados – casos de uso Una aplicación útil de este tipo de diagramas consiste en describir la secuencia permitida de eventos externos que reconoce y maneja un sistema dentro del contexto de un caso de uso. Es útil para describir el orden legal de los eventos externos.

61 Diagrama de estados – casos de uso Ejemplos: –En el caso Comprar Productos de la aplicación del punto de venta, no está permitido efectuar la operación efectuarPagoConTarjeta mientras no haya ocurrido el evento terminarVenta. –En el caso Procesar Documento en un procesador de texto, no está permitido efectuar la operación Guardar en Archivo mientras no haya ocurrido el evento Crear Archivo Nuevo o Abrir Archivo.

62 Diagrama de estados – comprar productos EnEsperadelaVenta EnEsperadelPago efectuarPago Eventodelsistema (externo) IntroduciendoProductos introducirProducto terminarVenta introducirProducto

63 Diagrama de estados del Sistema de Servicio a Clientes

64 Diagramas que describen el estado de los objetos Diagramas de Actividades –Los diagramas de actividades se utilizan para representar gráficamente el flujo secuencial de actividades de un proceso de negocios o un caso de uso. –También pueden ser utilizados para modelar las acciones que serán realizadas cuando una operación se está ejecutando así como los resultados de dichas acciones.

65 Input Request Route to Manager Evaluate Need Check Budget [need] [budget] [no need][no budget Disapprove Request Approve Request Route to Purchasing Agent Diagrama de Actividades

66 Diagramas que describen el comportamiento de los objetos Diagramas de Secuencia –Los diagramas de secuencia representan gráficamente cómo los objetos interactúan entre sí vía mensajes en la ejecución un caso de uso. –Ilustran cómo se envían y reciben los mensajes entre los objetos y en qué secuencia.

67 Eventos y operaciones del sistema Evento del sistema –Es un hecho externo que un actor realiza y produce una entrada al sistema. Operación del sistema –Es una acción que el sistema ejecuta en respuesta a una evento del sistema. Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito y no en el nivel del medio físico de entrada o de elementos de la interfaz.

68 Eventos y operaciones del sistema (2) Ejemplo: –Cuando un cajero genera un evento introducirProducto, causa la ejecución de la operación introducirProducto. El nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo y la operación es la repuesta (lo mismo sucede con los mensajes y los métodos).

69 Registro de las operaciones de un sistema Para determinar el conjunto de operaciones requeridas del sistema se identifican sus eventos. Cuando se utilizan parámetros, las operaciones son las siguientes: –IntroducirProducto(CUP, Cantidad) –TerminarVenta() –EfectuarPago(monto)

70 Diagrama de Secuencia – Comprar Productos Identificar eventos del sistema: –Primero debemos determinar los actores que interactúan directamente con el sistema de software. –El cliente interactúa con el cajero, pero no directamente con el sistema TPDV; esto sólo lo hace el cajero. –Por tanto, el cliente no es un generador de eventos del sistema, sólo el cajero lo es.

71 Diagrama de Secuencia – Comprar Productos Curso normal de los eventos en el caso Comprar Productos : Cajero :Sistema 1: introducir Producto(CUP, cantidad) 2: terminarVenta() 3: efectuarPago(monto) Sistema como caja negra Evento del sistema Inicia una operación de sistema Actor

72 Diagrama de Secuencia También mejora la claridad si el nombre de un evento del sistema comienza con un verbo (agregar, introducir, terminar, efectuar), ya que recalca que los eventos están orientados a comandos. –Así, terminarVenta es preferible a OprimaTeclaEnter porque capta mejor el propósito de la operación: mantiene un carácter abstracto y no se pronuncia respecto a las decisiones de diseño sobre cuál interfaz sirve para capturar el evento del sistema.

73 Diagrama de Secuencia En cuanto a expresar las operaciones en el nivel de propósito, se debe tratar de alcanzar el nivel más alto o la meta final para asignar nombre a la operación. Por ejemplo, respecto a la operación que captura el pago: –IntroducirImporteOfrecido(monto) – deficiente –IntroducirPago(monto) – mejor –EfectuarPago –mejor aún

74 a Product a Member Order a Member Ordered Product an Order Processor a Club Member display member information validate item create item enter item (product number) select new order update address (address) verify member (member number) Diagrama de Secuencia

75 Los diagramas de secuencia se utilizan para modelar la lógica de los escenarios de uso. –Un escenario de uso es la descripción de una manera potencial en que se utilizará el sistema. Los diagramas de secuencia modelan de una manera visual el flujo de la lógica dentro de un sistema, permitiendo tanto documentar como validar la lógica subyacente. Se utilizan tanto para el análisis como para el diseño.

76 Diagrama de Secuencia La lógica de un escenario de uso puede describir: –Un caso de uso; la lógica descrita por el curso normal de los eventos o una porción de éste, más unos o más escenarios alternativos. –Parte de un caso de uso, quizás un curso alternativo. –Un conjunto de paso con la lógica contenida en varios casos de uso. Por ejemplo, un alumno se inscribe en la universidad y además se inscribe inmediatamente en tres cursos.

77 Diagrama de Secuencia

78 Elementos de un Diagrama de Secuencia Los rectángulos en la parte superior del diagrama representan objetos, clases, actores, o casos de uso. Objetos y Clases –Dado que es posible enviar mensajes tanto a objetos como a clases, tiene sentido incluir tanto a objetos como a clases en los diagramas de secuencia. Los objetos responden a los mensajes a través de la llamada a una operación. Las clases lo hacen a través de la llamada a una operación estática. Actores –Los actores inician y tienen una participación activa en los escenarios de uso.

79 Elementos de un Diagrama de Secuencia Para los objetos, clases y actores se utilizan etiquetas estándar en el formato UML: Objetos: nombre:NombreDeLaClase –Donde nombre es opcional (los objetos a los que no se les da un nombre en el diagrama se llaman objetos anónimos). Clases: NombreDeLaClase Actores: NombreActor

80 Elementos de un Diagrama de Secuencia Ejemplo: Cliente

81 Elementos de un Diagrama de Secuencia Las líneas discontinuas que cuelgan de los rectángulos se llaman líneas de vida del objeto, y representan la vida del objeto durante el escenario que está siendo modelado. Los rectángulos largos y finos en las líneas de vida son rectángulos de invocación a métodos, e indican que operación se debe ejecutar en el objeto/clase que está recibiendo el mensaje.

82 Elementos de un Diagrama de Secuencia La "X" en la parte inferior de un rectángulo de invocación es una convención de UML para indicar que un objeto ha sido eliminado de la memoria, típicamente como resultado de recibir un mensaje con el estereotipo >. Los mensajes se indican como flechas etiquetadas –Cuando el emisor y el receptor de un mensaje es un objeto o una clase, la etiqueta corresponde al método que se invocará como respuesta al mensaje. –Si el emisor o el receptor es un actor humano entonces el mensaje se etiqueta con un texto breve que describe la información que está siendo comunicada.

83 Diagramas que describen el comportamiento de los objetos Diagramas de Colaboración –Los diagramas de colaboración son similares a los diagramas de secuencia, pero no se centran en la sincronización o "secuencia" de mensajes, si no que presentan la interacción (o colaboración) entre los objetos en un formato de red.

84 Diagrama de Colaboración El diseño orientado a objetos tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales. Un paso esencial en esta fase es la asignación de responsabilidades entre los objetos y mostrar como interactúan a través de mensajes. El diagrama de colaboración presenta el flujo de mensajes entre las instancias y la invocación de métodos.

85 Diagrama de Colaboración – juego de dados La figura muestra gráficamente los elementos esenciales del juego, enviando mensajes a las instancias de las clases Jugador y Dado. :Jugadord1:Dado jugar() 1:r1:= lanzar() d2:Dado 2:r2:= lanzar()

86 Diagramas de Colaboración y de Secuencia Los diagramas de colaboración describen las interacciones entre los objetos en un formato de grafo o red: Los diagramas de secuencia describen las interacciones en una especie de formato de cerca o muro: Instancia1 :ClaseAInstancia2 :ClaseB 1:mensaje2()2:mensaje3() mensaje1() Instancia1 : ClaseA Instancia2 : ClaseB mensaje2() mensaje3() mensaje1()

87 Diagramas que describen la implementación de los objetos Diagramas de Componentes –Los diagramas componentes se utilizan para representar gráficamente la arquitectura física del sistema. Pueden ser utilizados para demostrar cómo el código de programación se divide en módulos (o componentes).

88 Client Source Code Comment (client.exe) Drawing Library Comment (drawing.dll) dependency Diagrama de Componentes

89 Diagramas que describen la implementación de los objetos Diagramas de Despliegue –Los diagramas del despliegue describen la arquitectura física del hardware y software en el sistema. Representan las componentes de software, los procesadores, y los dispositivos que forman la arquitectura del sistema.

90 Application Server - Compaq PIII 500 Client Workstation HP Kayak XU-400 Database Server - Compaq PIII 500 SAP R/3 Comment Client Source Code Comment (client.exe) Oracle 8 Comment TCP/IP Diagrama de Despliegue


Descargar ppt "UML José Vargas Mery. Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un sistema –Casos de Uso –Estructura –Estado –Comportamiento."

Presentaciones similares


Anuncios Google