Unidad5DocumentacionUML

8/18/2019 Unidad5DocumentacionUML

1/95

Documentación de Análisis y Diseño del EnfoqueLenguajes de Programación

Juan José Ramírez Lama

[email protected]

www.juaramir.com

Departamento de Ciencias Exactas

Ingeniería Civil en Informática

http://find/http://www.juaramir.com/mailto:[email protected]


2/95

Contenido

Contenido

1 Introducción 3

2 Diagramas de Casos de Uso 12

3 Diagrama de Actividad 35

4 Diagrama de Clases 40Relaciones entre Clases 56Ejercicios 77

5 Diagrama de Secuencia 81

6 Diagrama de Estado 90

7 Resumen UML 93

Juan José Ramírez Lama (ULagos) Documentación de Análisis y Diseño 2016-1 - @juaramir 2 / 95

http://www.twitter.com/juaramir.pdfhttp://find/


3/95

Introducción

Contenido

1 Introducción 3






7 Resumen UML 93




4/95

Introducción

¿Qué es UML?

UML: Unified Modeling Language (Lenguaje Unificado deModelado).Estándar no propietario para modelar sistemas de software, OMG(Object Management Group).Convergencia de nociones usadas en métodos orientados a objeto.

Uso: Especificar, visualizar, construir y documentar artefactos deun sistema software.

Versión actual: UML 2.5 alpha (2012).

Se diseño para independizarlo del método de desarrollo, y se

intenta que sea aplicable a todas las etapas del ciclo de vida delsoftware.

Puede modelar el 80 % de la mayoría de los problemas usando alrede-dor del 20 % de UML




5/95

Introducción

Herramientas

Herramientas comerciales: Rational (IBM), Together (Borland),Visual Architect (Procesos de negocios BCD)

Herramientas Open Source: ArgoUML, StarUML, Umbrello.

Comercial y Open Source: PoseidonUML (Gentleware), Magic-Draw, Visual Paradigm.


http://www.twitter.com/juaramir.pdfhttp://goforward/http://find/http://goback/


6/95

Introducción

UML “Unificado”

Cruza los métodos y notaciones.

Cruza los ciclos de desarrollo.

Cruza los dominios de aplicación.Cruza las plataformas y lenguajes de implantación.

Cruza los procesos de desarrollo.

Cruza los conceptos internos




7/95

Introducción

Inconvenientes

UML no es una metodología.

No cubre todas las necesidades de especificación de un proyectode software. Por ejemplo, no define los documentos textuales.


I d ió



8/95

Introducción

Presentación UML

Diagramas de Clase

Describe la estructura estática del sistema: Objetos, atributos,asociaciones.

Diagramas de EstadoDescribe el comportamiento dinámico de un objeto individual

Diagrama de Casos de UsoDescribe el comportamiento funcional del sistema como lo ve elusuario.

Diagramas de Secuencia/interacciónDescribe el comportamiento dinámico entre los objetos del sistema.

Diagramas de Actividad/implementaciónDescribe el comportamiento dinámico de un sistema, en particularel flujo de trabajo.

Diagrama de Despliegue: Muestra el reparto de procesos.


I t d ió



9/95

Introducción

UML: Convenciones Básicas

Todos los diagramas UML corresponden a grafos con nodos yaristas

Los nodos son entidades y se dibujan como rectángulos u óvalos.

Los rectángulos representan clases o instanciasLos óvalos representan funciones

Los nombres de las Class no se subrayan.Una arista entre dos nodos representa una relación entre lasentidades correspondientes.


Introducción



10/95

Introducción

UML estático

Vista Diagramas Conceptos Principales

Estática Clases Clase, asociación, generalización,dependencia, realización, interfase

Caso de uso Caso de uso Caso de uso, actor, asociación,

extención, inclusión, generalizaciónde caso de uso

Implementación Componentes Componente, interfaz, dependen-cia, realización

Despliegue Despliegue Nodo, componente, dependencia,locación


Introducción

http://www.twitter.com/juaramir.pdfhttp://find/http://goback/


11/95

Introducción

UML dinámico

Vista Diagramas Conceptos Principales

Máquina deestado

Estado Estado, evento, transición, acción

Actividades Actividad Estado, actividad, transición decompleción, Juntura, BifurcaciónInteracción Secuencia Interacción, objeto, mensaje, activi-

dadInteracción Colaboración Colaboración, interacción, rol de

colaboración, mensaje


Diagramas de Casos de Uso



12/95


Contenido

1 Introducción 3






7 Resumen UML 93





13/95


Casos de Uso

Usado durante el análisis y captura de requisitos para representar elcomportamiento externo ("visible desde fuera del sistema"), Por ejem-plo:

Obtener dinero desde un cajero automático.

Comprar un ítem en la tienda.

Es una técnica para capturar información respecto de los servicios queun sistema proporciona a su entorno.

No pertenece estrictamente al enfoque orientado a objetos, es una téc-nica para capturar y especificar requisitos.





14/95


Casos de Uso: Primeros Pasos

Los diagramas de casos de uso representan la funcionalidad delsistema desde el punto de vista del usuario.





15/95

g

Diagrama de Casos de Uso

Modela la funcionalidadde un sistemapercibido desde elusuario externo (actor).

Un Actor representaun rol, es decir, un tipode usuario del sistema.

Un caso de uso es una unidad

funcional coherente expresado comouna transacción entre actores y elsistema.

Pueden describirse en varios niveles

de detalle.Un caso de uso se implementa comouna colaboración en la vista deinteracción.

Modelos de Caso de Uso: Elconjunto de casos de uso quedescriben completamente lafuncionalidad del sistema.





16/95

g

Actores

Un actor es un modelo (rol) para una entidad externa queinteractúa (se comunica) con el sistema:

UsuarioSistema externo (otro sistema)Medio ambiente fisico (clima).

Un Actor no necesariamente representa a una persona enparticular, sino más bien la labor que realiza frente al sistema.Un actor tiene un único nombre y una descripción opcional.Ejemplos de nombre y descripción:

Pasajero: Una persona en el tren.Satélite GPS: Un sistema externo que proporciona coordenadasGPS al sistema.





17/95

Caso de Uso

Un caso de uso representa una operación o tarea específica quese realiza tras una orden de algún agente externo, originada por

una petición de un actor o bien desde la invocación desde otrocaso de uso.Los casos de uso se pueden describir textualmente, con unenfoque en el flujo de eventos entre el actor y el sistema.La descripción textual del caso de uso consta de 6 partes:

1 Nombre único.2 Actores participantes.3 Condiciones de entrada.4 Condiciones de salida.5 Flujo de eventos.6

Requisitos especiales.Juan José Ramírez Lama (ULagos) Documentación de Análisis y Diseño 2016-1 - @juaramir 17 / 95




18/95

Ejemplo descripción textual de Caso de Uso

1 Nombre: Compra boleto2 Actor Participante: Pasajero3 Condición de entrada:

El Pasajero se para frentedel vendedor de boletos.

El Pasajero tiene suficientedinero para comprar elboleto.

4 Condición de salida: ElPasajero tiene un boleto.

5 Flujo de eventos:1 El Pasajero selecciona el

número de zonas a visitar.2 El vendedor de Boletos

despliega la cantidadadeudada.

3 El Pasajero inserta dinero,al menos la cantidadadeudada.

4 El vendedor entrega elvuelto.

5 El vendedor entrega elboleto.

6 Requerimientos espaciales:ninguno.





19/95

Ejemplo





20/95

Relaciones

1 Relación asociación

Es el tipo de relación más básica que indica la invocación desde unactor o casos de uso a otra operación (caso de uso)

2 Relación Dependencia o instanciaciónEs una forma muy particular de relación entre clases, en la cualuna clase depende de otra, es decir, se instancia (se crea).

3 Relaciones de GeneralizaciónOrientado exclusivamente para casos de uso (y no para actores).Se diferencia por el estereotipo «uses» o «includes» (uso) o por«extends» (herencia).

Relación includes/uses: Se recomienda utilizar cuando se tiene unconjunto de características que son similares en más de un caso deuso y no se desea mantener copiada la descripción de lacaracterística.Relación Extends: Se recomienda utilizar cuando un caso de uso essimilar a otro (en sus características).





21/95

La relación «extends»

Relaciona casosexcepcionales o invocados

rara vez.Los eventos excepcionalesson factorizados fuera delflujo de eventos principal

para mayor claridad.La dirección de unarelación «extends» eshacia el caso de usoextendido.

Los casos de uso querepresentan los flujosexcepcionales puedenextender más de un caso

de uso.Juan José Ramírez Lama (ULagos) Documentación de Análisis y Diseño 2016-1 - @juaramir 21 / 95




22/95

La relación «includes»

Esta relación representa lafuncionalidad comúnrequerida por dos o máscasos de uso.

Su comportamiento estafactorizado fuera para reuso,no porque sea una excepción.

La dirección de esta relaciónes hacia el caso de uso que la

está usando (a diferencia de«extends»).





23/95

Ejemplo de generalización de extensión e

inclusión



Ej l Má i R i l d



24/95

Ejemplo Máquina Recicladora

Sistema que controla una máquina de reciclado de botellas, tarros y jabas.El sistema debe controlar y/o aceptar:

Registrar el número de ítemes ingresados.Imprimir un recibo cuando el usuario lo solicita:

1 Describe lo depositado.2 El valor de cada ítem.3 Total.

El usuario/cliente presiona el botón de comienzo.Existe un operador que desea saber lo siguiente:

1 Cuantos ítemes han sido retornados en el día.2 Al final de cada día el operador solicita un resumen de todo lo

depositado en el día.El operador debe además poder cambiar:

1 Información asociada a ítemes.2 Dar una alarma en el caso de que:

Item se atora.No hay más papel.



Má i R i l d Id tifi ió d A t



25/95

Máquina Recicladora: Identificación de Actores



Má i R i l d C d U

http://www.twitter.com/juaramir.pdfhttp://goforward/http://find/http://goback/


26/95

Máquina Recicladora: Casos de Uso



Má i R i l d C d U



27/95




Máquina Recicladora Casos de Uso



28/95




Máquina Recicladora: Diagrama Completo



29/95

Máquina Recicladora: Diagrama Completo



Ejemplo Descripción de un Caso de Uso



30/95

Ejemplo Descripción de un Caso de Uso

Caso de uso: Abrir archivo

Casos de uso relacionados:

Generación de:

Abrir archivo digitando el nombre

Abrir archivo por selecciónPasos:

Acciones del actor Respuesta del sistema

1. Aparece diálogo abrir archivo

2. Especifica nombre del archivo3. Confirma selección 4. Desaparece Dialogo



Ejemplo (continuación)



31/95


Caso de uso: Abrir archivo digitando nombre


Especificación de: Abrir ArchivoPasos:

Acciones del actor Respuesta del sistema1. Aparece diálogo para abrir archivo

2a. Selecciona campo de texto2b. Digita nombre de archivo

3. Hace clic en abrir 4. Desaparece Dialogo






32/95


Caso de uso: Abrir archivo por selección


Especificación de: Abrir Archivoincluye: Elegir archivoPasos:

Acciones del actor Respuesta del sistema

1. Aparece diálogo para abrir archivo2. Elegir archivo

3. Confirmar Selección 4. Desaparece Dialogo






33/95


Caso de uso: Intentar abrir un archivo que no existe

Casos de uso relacionados:Especificación de: Abrir archivo digitando el nombrePasos:

Acciones del actor Respuesta del sistema1. Aparece diálogo abrir archivo

2a. Selecciona campo de texto2b. Digita nombre de archivo

3. Hace clic en abrir 4. Sistema indica archivo no existe5. Corrige el nombre del archivo6. Hace clic en abrir 7. Desaparece Dialogo

Caso de uso: Abrir archivo por selección (inclusión)Acciones del actor Respuesta del sistema1. Si no se despliega el archivo deseado, selec-

ciona un directorio

2. Se despliega el contenido del directorio

3. Repita (1.) hasta que se despliegue el archivodeseado4. Seleccione un archivo



Resumiendo



34/95

Resumiendo

Un diagrama de Casos de uso muestra una descripción genéricade un sistema desde el punto de vista de la funcionalidad que ve

el usuario.Cada caso de uso se transforma en un elemento de análisis, dise-ño e implementación, Con lo que mejora la “gestión” del desarrollo.


Diagrama de Actividad

Contenido



35/95

Contenido

1 Introducción 3






7 Resumen UML 93






36/95


Un diagrama de actividad es un caso especial de diagrama deestado.

Lo estados son actividades ("funciones").

Un diagrama de actividad es útil para describir el flujo de trabajode un sistema.



Permiten Modelar Decisiones



37/95

Permiten Modelar Decisiones



Permiten Modelar Concurrencia



38/95

Permiten Modelar Concurrencia

Sincronización de múltiples actividades.Dividir el flujo de control en múltiples hilos o secuencias.



Agrupación de Actividades



39/95

Agrupación de Actividades

Las actividades se pueden agrupar en carriles (o columnas) parahacer notar el objeto o subsistema que implementa talesactividades.


Diagrama de Clases

Contenido



40/95

1 Introducción 3






7 Resumen UML 93


Diagrama de Clases

Diagrama de Clases



41/95

g

El diagrama de clases es el diagrama principal para el análisis ydiseño del sistema.

Un diagrama de clases presenta las clases del sistema con sus

relaciones estructurales y de herencia.La definición de clase incluye definiciones para atributos yoperaciones.

El modelo de casos de uso debería aportar información paraestablecer las clases, objetos, atributos y operaciones.


Diagrama de Clases

Diagrama de Clases



42/95

g

Modela los conceptos de dominio de la aplicación.

Permite visualizar las relaciones entre las clases que involucran elsistema.

Un diagrama de clases está compuesto por los siguienteselementos:

Clases: atributos, operaciones y visibilidad.Relaciones: herencia, composición, agregación, asociación y uso.Responsabilidades


Diagrama de Clases

Se define entonces. . .



43/95

Persona

nombre: palabrasfecha nacimiento: fechaaltura: metroestado civil: (soltero/casado)sexo: (femenino/masculino)nacertrabajar

pagar impuestos


Diagrama de Clases

Visibilidad en Orientación a Objetos



44/95

p u b l i c c la ss Persona {String nombre ;String direccion ;String rut ;p r i v a t e i n t sueldo ;

Persona ( String nombre , String dirección , String ←rut ) {

t h i s . nombre=nombre ;t h i s . direccion=direccion ;t h i s . rut=rut ; }

p u b l i c v oi d nacer ( ) { . . . }

p u b l i c v oi d trabajar ( ) { . . . }

p u b l i c v oi d pagarImpuestos ( Impuestos i ) { . . . }}


Diagrama de Clases

Entonces. . .



45/95


Diagrama de Clases

Lo esencial del Diagrama de Clases UML



46/95

Los principales símbolos que se muestran en un diagrama de clasesson:

Clases: representan los tipos de datos mismos.

Asociaciones: representan los enlaces entre las instancias de

clases.Atributos: son datos simples que se ubican en clases y susinstancias.

Operaciones: representan las funciones realizadas por las clasesy sus instancias.

Generalizaciones: agrupa clases en jerarquías de herencia.


Diagrama de Clases

Diagrama de Clases



47/95

Los diagramas de clases representan la estructura del sistema


Diagrama de Clases

Diagrama de Clases



48/95

Una clase se representa en forma simple como una caja con el

nombre de la clase dentro.El diagrama puede mostrar también los atributos y operaciones.La cabecera completa de una operación es:

nombreOperacion(nombreParametro: tipoParametro ...):

tipoRetorno


Diagrama de Clases

Clase



49/95

Una clase representa un concepto.

La clase encapsula estado (atributos) y comportamiento(operaciones).Cada atributo tiene un tipo.Cada operación tiene una cabecera.

El nombre de la clase es la única información obligatoria.


Diagrama de Clases

Clase



50/95

Los diagramas de clases representan la estructura del sistema.


Diagrama de Clases

Atributo



51/95

Los atributos describen a una clase. Pueden ser Públicos,Privados o Protegidos.

Públicos (+): indica que el atributo será visible tanto dentro comofuera de la clase, es decir, es accesible desde todos lados.Privado (-): Indica que el atributo solo será accesible desde dentrode la clase (solo sus métodos lo pueden acceder).Protegido (#): Indica que el atributo no será accesible desde fuerade la clase, pero si podrá ser accesado por métodos de la clase,además de las subclases que se deriven (herencia).


Diagrama de Clases

Operaciones (métodos)



52/95

Las operaciones o métodos de una clase describen la forma en lacual ésta interactúa con su entorno. Pueden ser Públicas,Privadas o Protegidas.

Públicos (+): Indica que el método será visible tanto dentro comofuera de la clase, es decir, es accesible desde todos lados.Privado (-): Indica que el método solo será accesible desde dentrode la clase (solo otros métodos de la misma clase lo puedenacceder).Protegido (#): Indica que el atributo no será accesible desde fuerade la clase, pero si podrá ser accesado por métodos de la clase,

además desde las subclases que se deriven (herencia).


Diagrama de Clases

Instancias



53/95

Una instancia representa un fenómeno.

Los atributos se representan con sus valoresEl nombre de una instancia se subraya

El objeto puede contener solo el nombre de la clase (instanciaanónima).


Diagrama de Clases

Clase



54/95

El diagrama de Clases representa la estructura del sistema.

Usado:Durante el análisis de requerimientos para modelar los conceptosdel dominio de la aplicación.Durante el diseño del sistema para modelar subsistemas.Durante el diseño de objetos para especificar el comportamiento y

atributos detallados de las clases.


Diagrama de Clases

Relaciones entre Clases



55/95

Las clases interrelacionadas modelan un sistema en sudimensión estática.

Existen tres tipos de relaciones básicas:Dependencia.Generalización.Asociación.


Diagrama de Clases Relaciones entre Clases

Contenido



56/95

1 Introducción 3






7 Resumen UML 93



Dependencia (Instanciación o uso)



57/95

Un cambio en la clase independiente (Aplicación) puede afectar ala clase dependiente (Ventana).

La interpretación más frecuente es la de uso: una clase usa a otracomo argumento de una operación.

El objetivo creado no se almacena en el objeto que lo crea.



Dependencia (Instanciación o uso)



58/95

ActorUna entidad fuera del sistema a ser modelado, interactuando con elsistema ("Pasajero").

ClaseUna abstracción que modela una entidad de la aplicación odominio de la solución.La clase es parte del modelo del sistema (Üsuario","VendedorBoletos", "Servidor").

Objeto

Una instancia específica de una clase ("Joe, el pasajero que estácomprando un boleto al vendedor de boletos").



Generalización



59/95

Relaciona una abstracción general (superclase) con una más con-creta del mismo tipo (subclase).

Una clase puede tener cero, una (herencia simple) o más super-clases (herencia multiple).Una clase sin superclases es una una clase raíz.

Una clase sin subclases es una clase hoja.



Generalización - Polimorfismo



60/95

Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones.

Un objeto de una subclase puede sustituir a un objeto de la super-

clase en cualquier contexto. Lo inverso no es cierto.Una operación de la superclase la anula y sustituye.

El polimorfismo es muy útil en la programación.



Generalización



61/95



Asociaciones



62/95

Las asociaciones denotan relaciones entre clases.La multiplicidad del extremo de una asociación denota cuántosobjetos puede referenciar la instancia de una clase.



Asociación



63/95

Relación estructural entre las clases.

En general es simétrica.Tiene un nombre, que l describe (verbo, con dirección de lectura).

Puede tener un rol que describe que una clase juega en unaasociación.

Tiene multiplicidad, que especifica por cada clase el número deobjetos de la clase opuesta que se relacionan con un solo objetode dicha clase a través de la asociación:

1: uno0..1: cero o uno3: tres*: muchos o n1..*: al menos uno2,6,7: dos, seis o siete2-4, 10-12: de dos a cuatro y de diez a doce



1 a 1, 1 a muchos y muchos a muchos



64/95



Asociación



65/95



De la Especificación del Problema al Modelo de

Objeto



66/95

j

Especificación del Problema: Una bolsa de valores lista muchas empre- sas . Cada empresa es individualizada de manera inequívoca mediante

un identificador .

Diagrama de Clases:



De la Especificación del Problema al Código

Especificación del Problema: Una bolsa de valores lista muchas empre



67/95

Especificación del Problema: Una bolsa de valores lista muchas empre- sas . Cada empresa es individualizada de manera inequívoca mediante

un identificador .Diagrama de Clases:

p u b l i c c la ss BolsaDeValores {p r i v a t e VectormisEmpresas= new Vector ( ) ; } ;p u b l i c c la ss Empresa {p ub l i c i n t identificadorp r i v a t e Vector misBolsasDeValores =←

new Vector ( ) ; } ;



Agregación

R l ió di á i d d l ti d id d l bj t i l id



68/95

Relación dinámica, en donde el tiempo de vida del objeto incluidoes independiente del que lo incluye.

El objeto base utiliza al incluido para su funcionamiento, como unparámetro pasado “por referencia”.Es un caso especial de asociación que denota una jerarquía“consta-de” (o una relación "todo-parte").El todo es la clase padre, los componentes son las clases hijas.



Composición

Un rombo relleno indica composición: Una forma fuerte de



69/95

Un rombo relleno indica composición: Una forma fuerte deagregación donde el tiempo de vida de las instancias

componentes es controlada por el todo. Esto es, las partes noexisten por si mismas (“el todo controla/destruye las partes”).Relación estática, en donde el tiempo de vida del objeto incluidoestá condicionado por el tiempo de vida del que lo incluye.El objeto base se construye a partir del objeto incluido, es decir,es “parte/todo” como un parámetro pasado “por valor”.



Clasificadores

Los clasificadores pueden ser usados para reducir la multiplicidad de



70/95

Los clasificadores pueden ser usados para reducir la multiplicidad deuna asociación



Herencia

U li ió d l l li fi t l d



71/95

Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones.

Es otro caso especial de una asociación, denotando una jerarquía“es un(a)” o “es un tipo de”.

La herencia simplifica el modelo de análisis al introducir unataxonomía.

Las clases hijas heredan los atributos y operaciones de la clasepadre.

El polimorfismo es muy útil en la programación.



Herencia



72/95



Paquete

Los paquetes ayudan a organizar los modelos UML para



73/95

Los paquetes ayudan a organizar los modelos UML paraaumentar su legibilidad.

Se puede usar el mecanismo de paquetes UML para organizarlas clases en subsistemas.Todo sistema complejo puede ser descompuesto en subsistemas,donde cada subsistema es modelado como un paquete.



Responsabilidades: Tarjetas CRC



74/95

La distribución de responsabilidades en un sistema, se realiza

identificando un conjunto de clases que colaboran entre sí para llevara cabo algún comportamiento. Luego hay que identificar el conjunto de

responsabilidades para cada clase.

Tarjetas de Clase-Responsabilidad-Colaboración (CRC)

Nombre de la Clase: PedidoResponsabilidad ColaboraciónRevisa si hay elementos en existencia Línea de pedidoDetermina precio Línea de pedidoRevisa si el pago es válido ClienteDespacha a la dirección de entrega



Ejemplo diagrama de clases



75/95



Ejemplo diagrama de clases



76/95


Diagrama de Clases Ejercicios

Contenido



77/95

1 Introducción 3






7 Resumen UML 93



Ejercicio 1



78/95

En una empresa de desarrollo de sistemas informaticos se desea llevar un control eficiente

de los trabajadores del centro y los proyectos que se realizan.La empresa esta dividida en grupos los cuales tienen como maximo 10 trabajadores.

Los trabajadores estan clasificados en tres tipos de acuerdo a sus funciones. De cadatrabajador se tiene nombre, carne de identidad, anos trabajados, y su salario basico.

Los analistas adquiriran un extra del 30 % de su salario basico y de tener 10 anos o masen la empresa recibiran $30 mas. Los disenadores adquiriran un extra de un 25 % + $15

en caso de tener 10 o mas anos. Los programadores recibiran solo un extra del 20 % de sutrabajo.

Cada proyecto se le asigna a un grupo determinado, y un grupo tiene un solo proyectoasociado. De cada proyecto se conoce su identificador, descripcion, cliente, fecha de termi-nacion y sistema operativo en que se realiza.

1 Identifique las clases necesarias para dar solucion a esta problematica.2 Realice el diagrama de clases



Solución



79/95



Ejercicio 2

En una residencia estudiantil los datos que se guardan de cada becado son: nombre ce



80/95

En una residencia estudiantil los datos que se guardan de cada becado son: nombre, ce-dula de identidad, ano y carrera que cursa y la evaluacion como becario, dada por cada

uno de los factores: Jefe de Residencia, Jefe de Dpto. y Profesor que atiende el Dpto.La evaluacion de cada factor es una nota entre 2 y 5. En caso que el estudiante sea extran- jero, se debe tener ademas su pais de procedencia, numero de pasaporte, la direccion desu embajada y ano de entrada al pais.

Ademas, para el caso de estos estudiantes debe guardarse la evaluacion dada por un factoradicional, el Jefe de relaciones internacionales. En caso de que el estudiante sea chileno,

debe almacenarse su direccion particular.Para cada becado se obtiene su evaluacion de la siguiente manera: si una de sus evalua-ciones es de 2 puntos, la evaluacion del becado es de Mal, aunque sean de 5 todas lasdemas, si el promedio de estas es mayor e igual que 3 y menor que 4, su evaluacion serade Regular, en caso de que el promedio este entre 4 y 4.75, incluyendo ambos valores, suevaluacion sera de bien y un promedio superior a 4.75 hara que se evalue de Excelente.

Tenga en cuenta que la beca solo tendra capacidad para 3000 estudiantes.

1 Identifique las clases necesarias para dar solucion a esta problematica.2 Realice el diagrama de clases


Diagrama de Secuencia

Contenido



81/95

1 Introducción 3






7 Resumen UML 93




Los diagramas de secuencia representan el comportamiento de un sis-é d j (‘i i ”) dif bj



82/95

tema a través de mensajes (‘interacciones”) entre diferentes objetos.






83/95

Usado en el análisis.

Para refinar las descripciones de los casos de uso.Para encontrar objetos adicionales (“objetos participantes”).Mensajes → Operaciones en los objetos participantes.

Usado en el diseño del sistema.Para refinar las interfaces de subsistemas.

Las instancias se representan mediante rectángulos. LosActores Mediante figuras.

Las Líneas de vida se representan mediante líneas discontinuas.

Los Mensajes se representan mediante flechas.

Las Activaciones se representan mediante rectángulosangostos.






84/95






85/95



Diagrama de Secuencia como Flujos de Datos

El origen de una flecha indica la activación que envió el mensaje.



86/95

Las flechas horizontales discontinuas pueden indicar también flujo

de datos por ejemplo retorno de los resultados de un mensaje.



Diagrama de Secuencia: Iteración y Condición

Una iteración se denota mediante un * delante del nombre delj



87/95

mensaje.

Una condición se denota mediante una expresión lógicaencerrada entre [ ] delante del nombre del mensaje.



Diagrama de Secuencia: Creación y Destrucción

La creación se denota mediante un mensaje sobre una líneaap ntando al objeto



88/95

apuntando al objeto.

La destrucción se denota mediante una marca X que destruye laactivación.En ambientes de recolección de basura, la destrucción se puedeusar para denotar el fin de la vida útil de un objeto.



Diagrama de Secuencia: Propiedades



89/95

El diagramas de secuencias UML representa comportamiento entérminos de interacciones.

Útil para identificar o encontrar objetos perdidos.

Consume tiempo construirlo, pero vale la pena la inversión.

Complementa el diagrama de clases (que representa estructura).


Diagrama de Estado

Contenido

1 I t d ió 3



90/95

1 Introducción 3



4 Diagrama de Clases 40

Relaciones entre Clases 56Ejercicios 77


6

Diagrama de Estado 90

7 Resumen UML 93


Diagrama de Estado

Diagrama de Estado



91/95

Representa el comportamiento de un único objeto cuyocomportamiento dinámico es interesante.


Diagrama de Estado

Diagrama de Actividad VS Diagrama de Estado

Diagrama de Estado para Incidentes



92/95

g p

Se enfoca en el conjunto de atributos de una sola abstracción (objeto,sistema)

Diagrama de Actividad para Incidentes

Se enfoca en el flujo de datos de un sistema


Resumen UML

Contenido

1 Introducción 3



93/95

1 Introducción 3



4 Diagrama de Clases 40

Relaciones entre Clases 56Ejercicios 77



7 Resumen UML 93

Juan José Ramírez Lama (ULagos) Documentación de Análisis y Diseño 2016 1 @juaramir 93 / 95

Resumen UML

Notaciones UML



94/95

UML proporciona muchas otras notaciones, por ejemplo:Diagramas de despliegue para modelar configuraciones.

Útil para pruebas y gestión de liberaciones.

UML proporciona una amplia variedad de notaciones paramodelar muchos aspectos de los sistemas de software.


Resumen UML

Resumen UML



95/95

UML proporciona una amplia variedad de notaciones paramodelar muchos aspectos de los sistemas de software.

Poderoso, pero complejo.

UML es un lenguaje de modelado.Pueden generarse modelos incomprensibles.Puede resultar incomprensible si se usan demasiadascaracterísticas exóticas (poco conocidas).


Unidad5DocumentacionUML

Documents

Transcript of Unidad5DocumentacionUML