Unidad 1 UML

1

UNIDAD I

INTRODUCCIÓN AL ANÁLISIS Y DISEÑO CON UML

Contenido Por qué modelamos

La importancia Cuatro principios del modelado Los planos básicos de un sistema software Modelado orientado a objetos

Qué es UML?. Presentación del UML Diagramas Utilizados en UML (ejemplos)

2

Por qué Modelamos

El modelado es una técnica de hacer

modelos, que ofrece

Una visión global del sistema.

3

Importancia de Modelar

Objetivos del Modelar:

Visualizar, especificar la estructura, proporcionan plantillas, documentan decisiones

4

Principios del Modelado

La elección de qué modelos crear, y dar forma a una solución.

Todo modelo puede ser expresado a diferentes niveles de precisión.

Los mejores modelos están ligados a la Realidad

Un único modelo no es suficiente.

5

Modelado orientado a objetos

UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite:

Especificar Construir Visualizar Documentar

los objetos de un sistema

6

U M L Qué es UML?.

UML puede ser utilizado por cualquier metodología de análisis y diseño orientada a objetos para expresar los modelos de diseño.

7

Qué es UML Este lenguaje es el resultado de la unificación

de los métodos de modelado orientados a objetos de:

Booch, Rumbaugh (OMT:Object Modeling

Technique) Jacobson (OOSE:Object-Oriented Sotfware

Engineering) .

8

Historia de UMLLa notación UML se deriva de y unifica, las tres metodologías de análisis y diseño O.O. más extendidas: •Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.

•Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique).

•Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).

9

Historia de UMLEl desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos.

A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.

10

Historia de UMLDe las tres metodologías iniciales, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración.

Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG (), que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.

11

Historia de UMLEn 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño O.O.

UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).

12

Historia de UML

Nov ‘97 UML aprobado por el OMG

1998

1999

2000

UML 1.2

UML 1.3

UML 1.4

2005? UML 2.0

Revisiones menores

UML 1.52003

*Desarrollo de Software Orientado a Objeto usando UML,

Patricio Letelier Torres, http://www.dsic.upv.es/~uml/cur

so.ppt 13

¡UML!

Es un lenguaje estándar para escribir planos de software.

Puede visualizar, especificar, construir y documentar los componentes de un sistemas OO que involucra una gran cantidad de software.

UML es apropiado para modelar sistemas de información en empresas hasta aplicaciones web. Es un lenguaje muy expresivo , cubre todas las vistas necesarias para desarrollar y desplegar sistemas.

14

¿Dónde puede utilizarse UML?

Sistema de Información Institucionales Bancos y Servicios Financieros Telecomunicaciones Transporte Comercio Electrónica médica Ámbito científico Servicios distribuidos basados en la

Web

15

1.1 ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

16

APLICACIÓN DEL LENGUAJE UML Y DEL ANÁLISIS Y EL

DISEÑO O.O ¿Qué significa contar con un sistema o.o que esté

bien diseñado?

Significa adquirir y utilizar habilidades prácticas en el diseño OO.

Estas destrezas son indispensables para crear sistemas de software bien diseñados, robusto y de fácil mantenimiento, utilizando la tecnología de objetos y los lenguajes de programación O.O como C++, Java, etc. 17

QUÉ SON EL ANÁLISIS Y EL DISEÑO O.O

La esencia del análisis y el diseño orientado a objetos consiste en situar el dominio de un problema y su solución lógica dentro de la perspectiva de los objetos.

Análisis Diseño Construcción

Investigación del problema

Solución Lógica Código

18


Durante el análisis orientado a objetos se procura ante todo identificar y describir los objetos o conceptos dentro del dominio del problema.

Por ejemplo:

Sistema de información de la biblioteca

Algunos Conceptos son:

Libro, Biblioteca y Cliente

19


Durante el diseño orientado a objetos se procura definir los objetos lógicos del software que finalmente serán implementados en un lenguaje de programación O.O.

Los objetos tienen atributos y métodos.

Ejemplo: Sistema de información de la biblioteca Objeto: Libro, Atributo titulo Método imprimir

20


Finalmente, durante la construcción o programación O.O se implementan los componentes del diseño, como una clase Libro en C++ o Java, etc.

Ejemplo:

Organización de la Empresa MicroChaos

21

Un proceso de desarrollo de software es un método de organizar las actividades relacionadas con la creación, presentación y mantenimiento de los sistemas de software.

EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO

22

El lenguaje UML estandariza los artefactos y la notación, pero no define un proceso oficial de desarrollo.

Algunas de las razones que explican esto:

1.- Aumentar las probabilidades de una aceptación generalizada de la notación estándar del modelado, sin la obligación de adoptar un proceso oficial.

2.- La esencia de un proceso apropiado admite mucha variación y depende de las habilidades del personal, de la razón investigación-desarrollo, de la naturaleza del tiempo, etc.


23

Una vez aclaradas estas razones, procedemos a aplicar los principios generales y los pasos normales que guían un proceso eficaz.

Pasos de macronivel:

En un nivel alto, los pasos principales en la presentación de una aplicación son los siguientes:


24

1.- Planeación y elaboración:

Planear, definir los requerimientos, construir

prototipos, etc. 2.- Construcción:

La creación del sistema. 3.- Aplicación:

La transición de la implementación del sistema a su uso.


25

Desarrollo iterativo

Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento secuencial de un sistema a través de múltiples ciclos de desarrollo de análisis, diseño, implementación y pruebas.

El sistema crece al incorporar nuevas funciones en cada ciclo de desarrollo. Tras una frase preliminar de planeación y especificación, el desarrollo pasa a la fase de construcción a través de una serie de ciclos de desarrollo.


26

Desarrollo iterativo

En cada ciclo se aborda un conjunto relativamente pequeño de requerimientos, pasando por el análisis, el diseño, la construcción y las pruebas. El sistema va creciendo en cada ciclo que concluye.

Esto contrasta con el ciclo clásico de la vida en cascada, en el cual las actividades (análisis y diseño, entre otras) se llevan a cabo una vez con todos los requerimientos del sistema.


27

Fijación de la duración de un ciclo de desarrollo

Una estrategia muy útil en los ciclos de desarrollo consiste en limitarlo a un marco temporal, esto es, un lapso rígidamente fijo, digamos cuatro o n semanas.

En un período menor sería muy difícil terminar las actividades; en un periodo mayor la complejidad se torna abrumadora y la retroalimentación se retras.


28

Bloques de Construcción UML

Bloques

Elementos

Relaciones

Diagramas

29


Elementos Relaciones Diagramas

Estructurales

Clase

Ventana O rigen T amaño A brir( ) Cerrar() M over( ) D ibujar( )

interfaz

Cadena de responsabilidad

Casos de uso Realizar Pedido

Clase activa GestorEventos

Suspender () VaciarCola()

nodo

servidor

Esperando

EstadosComportamiento Dibujar

Mensajes

Agrupación

Reglas del negocio

Anotación

componente

Interacción

30

Elementos Estructurales Elementos estructurales, son la parte estática de un

modelo Clase: representa un conjunto de objetos que

comparten los mismos atributos, operaciones, relaciones y semántica.

Publicación

Código P Cadena(2)Copias EnteroImporte Decimal(10,2)

Agregar()Consultar()Listar()

Nombre de la clase

Atributos

Operaciones

31

Elementos Estructurales Atributo: Representa una propiedad de una

entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado.

Objeto: Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos

32

Elementos Estructurales Interfaz: define un conjunto de

especificaciones de operaciones

Colaboración: define una iteración y es una sociedad de roles y otros elementos que colaboran cooperativamente

Cadena de Responsabilidad

33

Elementos Estructurales Caso de Uso: Conjunto de secuencia de

acciones que se ejecutan y el resultado es de interés para un actor en particular.

Realizar pedido

34

Elementos Estructurales Clase Activa: Son similares a las clases

excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos

Gestor Ventas

Suspender()VaciarCola()

Nombre

Operaciones

35

Elementos Estructurales Componentes: Es empaquetamiento físico

de diferentes elementos lógicos como clases, interfaces, y colaboraciones.

Orderform.java

36

Elementos Estructurales

Nodo: Es elemento físico es decir un recurso computacional

Servidor

37

Elementos Comportamiento

Son la parte dinámica, y representan comportamiento en el tiempo y el espacio.

Interacción: Conjunto de mensajes intercambiados entre objetos.

38

Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, recibe cierto tipo de estímulos y especifica la secuencia de estado por las que pasa un objeto

Elementos Comportamiento

Esperado

39

Elementos Agrupación

Elementos Agrupación son las partes organizativas

Un paquete: Mecanismo de propósito general para organizar elementos.

Reglas del Negocio

40

Elementos de Anotación

Elementos de Anotación son las partes explicativas, son comentarios, para describir, clasificar, y hacer observaciones

Nota: Sirve para hacer comentarios a un conjunto de elementos

Devuelve unaCopia del objetoreceptor

41


Elementos Relaciones Diagramas Dependencia

Relación entre dos elementos uno independiente a otro dependiente y puede afectar la semántica

Asociación Son conexiones entre objetos (rol, multiplicidad, calificador)

Generalización Especificación en donde el hijo comparte la estructura y el

comportamiento del padre

Realización Es una relación semántica entre clasificadores

0...1 *Patrón empleado

42

Elementos Relaciones Diagramas

Use CaseDiagramsDiagramas

Caso de Uso

ScenarioDiagramsDiagramas

Colaboración

StateDiagramsDiagramas

Componentes

ComponentDiagramsDiagramasDespliegue


Objecto

ScenarioDiagramsDiagramas

Estado

Use CaseDiagramsDiagramasSecuencia


Clase

DiagramasActividades

Modelos


43

Diagramas de clases

Un Diagrama de Clases muestra un conjunto de clases, interfaces, colaboraciones y relaciones.

Cubren la vista de diseño estático de un sistema

Cuando incluyen clases activas cubren la vista de procesos estáticos

44

Rol: Se identifica con un nombre al final de la línea y describe la semántica de la relación en el sentido indicado.

Cada asociación tiene dos roles; cada rol es una dirección y puede estar representado en el nombre de la clase.

Diagramas de clasesRelación de Asociación(Rol y Multiplicidad)

45

Multiplicidad:Describe la cardinalidad de la relación, es decir, cuantos objetos de esa clase pueden participar en la relación dada.

1

Exactamente unoClase

*

Cero a másClase0. ...1 Cero a unoClase

m. n Especificada numéricamenteClase

Diagramas de clasesRelación de Asociación(Rol y Multiplicidad)

46

Diagramas de clasesEjemploVendedor

NúmeroNombreDirección :

AsignarCuotaCalcularComisiones

VentaNúmeroFechaHora

CrearCalcularImporte

DetalleVenta

NúmeroRenglónCveArtículoCantidadImporte

CalcularIVACalcularImporte

Participa en

1..*

1..*

CLASES

RELACION

ATRIBUTOS

OPERACIONES

47

Diagramas de objetos

Diagrama de objetos muestra un conjunto de objetos y sus relaciones representan instantáneas de instancias de los elementos encontrados en los diagramas de clase.

Cubren la vista de diseño y proceso estático de un sistema

48

Diagramas de objetosEjemplo

Abstracciones más generales

Conceptos básicos de la Orientación a Objetos

Vehículo

Vehículo Terrestre Vehículo aéreo

Avión HelicópteroCoche Camión

49

Diagramas de casos de uso

Diagrama de casos de uso muestra un conjunto de casos de uso y actores y sus relaciones cubren la vista de casos de uso estática de un sistema.

Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de un sistema.

50

Diagramas de Casos de Uso

Cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo.

El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.

51

Actor: Es un usuario del sistema, que necesita o usa alguno o algunos de los casos de uso.

Un usuario puede jugar más de un rol.

Un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.


52

Tienen tres tipos de relaciones:Comunica: (comunicates): entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado. Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro. Se usa cuando se describe una variación sobre el normal comportamiento.


53

Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones).

Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.


54

Diagramas Casos de Usos

Comunica

<<use>>

Profesor

Actualizar carga academica

Actor

<<extend>>

Actualizar carga

Administrativa

Pedir Permiso

Elaborar Informe de Actividades

Elaborar Planificación de Actividad

55

Diagramas de secuencia

Diagrama de secuencia Es un diagrama de interacciones que resalta la ordenación temporal de los mensajes.

Es importante mencionar que los diagramas de interacción es un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos.

56

Diagrama de secuencia

:USUARIOAUTORIZADO

:TOTAL_D

ACTUALIZAR DEPOSITO F.T.

OK

Diagrama de secuencias asociadas al proceso “Actualizar Depósito”

ACTUALIZAR TOTAL_D

OK

ACTUALIZAR TOTAL_D

OK

ACTUALIZAR DEPOSITO F.T.

OK

:USUARIOAUTORIZADO

57

Diagramas de colaboración

Diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los objetos, que envían y reciben mensajes de las iteraciones que están indicadas por un número

A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales) y ciclos en la ejecución.

58

Diagramas de colaboración

Ejemplo

Cajero<<Cajero>> Aplicación : Cuenta cheques

: Cheque : Cliente

Interfaz Registra RetiroInfoCuentaFormateada C

heq

ueO

k

NumCliente, Nombre, SaldoCuenta

5.1 ValidaCheque(numCheque) Nom

reC

lien

te

3.1.1 ObtenerNombreCliente(NumCliente)

5.1.1 Valida Cheque No Robado (NumCheque)5.1.2 Valida Cheque No Canceladop (NumCheque)

Registra Retiro1 Arranca Aplicación2 Teclea Tipo mov3 Teclea num Cuenta4 Teclea Tipo Docto5 Teclea Num Cheque

59

Diagramas de Estado

Diagrama de estados (statechart) muestra una máquina de estados, que consta de estados transiciones, eventos y actividades.

Cubren la vista dinámica de un sistema y el comportamiento de una interfaz, clase, colaboración y resaltan el comportamiento dirigido por eventos de un objeto.

60

Diagramas de Estados

Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro

Esta representado principalmente por los siguientes elementos:

estado, elemento y transición.

61

Diagramas de EstadosEventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. -Condición que toma el de verdadero o falso.-Recepción de una señal o mensaje de otro objeto en el modelo.-Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular.

62

Diagramas de Estados

Transición: Es una relación de tres o más estados en una transición de múltiples fuentes o múltiples destinos.

63

Diagramas de EstadosEjemplo

Inicio

No se revisan todos los artículos/ obtiene siguiente artículo

Todos los artículos comprobados && todos los artículos disponibles

Todos los artículos comprobados && algunos artículos no en inventario

Artículo recibido Algunos artículos no en existencia Artí

culo re

cibi

do

Todo

s lo

s ar

tícul

os d

ispon

ible

s

Transición

EstadoAutotransición

Hace / revisaartículo

Hace /iniciaentrega

Espera Entregado

Comprobación Despachando

64

Diagramas de Actividades

Diagrama de actividades muestra el flujo de actividades dentro de un sistema.

Cubren la vista dinámica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de objetos.

65

Diagrama de ActividadesUn diagrama de actividades es un

diagrama de estados, casi todos los estados son estados de acción, y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior.

Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.

66

Diagrama de Actividades

Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos

Los elementos que conforman el diagrama son: acción y transición.

67


Transición: Es la relación entre dos estados y se encuentran unidos por flechas

Indican que un objeto que está en el primer estado, realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas

68


Ejemplo

Comprueba

artículo de línea

Reordena

artículo

Asigna orden

Despacha orden

Recibe orden

Cancela orden

Autoriza pago[Fallo]

[éxito]

[en existencia]

[se necesitaordenar]

[por cada artículo]

Condición de sincronización

[existencia asignada a todos los artículos de línea y pago autorizado]

69

Diagramas de Componentes

Diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes, cubren la vista de implementación estática.

Se relacionan con diagramas de clase en que un componente se corresponde con una o más clases, interfaces o colaboraciones.

70

Diagramas de Componentes

Representa las componentes físicas de la aplicación.

LISTADO

Reservación

AGENCIA DE VIAJES Actualizar

INTERFAZ

71

Diagramas de Despliegue

Diagrama de despliegue muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.

Su relación con los diagramas de componentes en que un nodo incluye, uno o mas componentes.

72

Diagrama de despliegue

Representa la visualización

de los componentes

sobre los dispositivos

físicos.

SERVIDOR

reservaciones

listado

<<Base de Datos >>

CLIENTE: PC

Agencia de Viajes

73

ConclusionesEn este trabajo se ha aprendido los conceptos de UML (El Lenguaje Unificado de Modelado), como es el vocabulario, reglas de construcción de modelos.

Se vio, los elementos sus relaciones y los 9 Diagramas que utiliza UML para su modelado de Sistemas

74

BibliografíaEl lenguaje unificado de

modelado

Grady BoochJames Rumbaugh

Ivar Jacobson

El libro introductorio a UML

Addison Wesley

75

Documents

Unidad 1 UML