Informe Diagramas Uml 3sa22

DIAGRAMAS DE CLASES EN UML

PRESENTADO POR: EDILBERTO GUTIÉRREZ PALACIOS

PRESENTADO A: WILSON LANCHEROS LOPEZ

CORPORACION UNIFICADA DE EDUCACIÓN SUPERIOR “CUN” FACULTAD DE INGENIERIA DE SISTEMAS PROGRAMACIÓN ORIENTADA A OBJETOS 2015

EDILBERTO GUTIERREZ PALACIOS

IINTRODUCCIÓN Generalizando al producirse cualquier requerimiento de un software, surgen ideas. Poniendo un ejemplo un general de un negocio que compra y vende productos, se observa que utilizado la informática puede mejorar sustancialmente su istración. Entonces, teniendo una idea bastante clara de su necesidad, acude a especialistas en desarrollo de software. Después de varias entrevistas, los especialistas determinan que deben cumplir con las siguientes etapas de trabajo para generar el software adecuado a los requerimientos de su cliente: 1. 2. 3. 4. 5. 6.

Relevamiento Análisis Diseño Desarrollo Capacitación Mantenimiento

El relevamiento consiste en un dialogo permanente de los especialistas y el cliente (puede incluir al personal de diferentes sectores del negocio) con el fin que los primeros identifiquen todos y cada uno de los componentes de dicho negocio y cómo interactúan. En definitiva, los especialistas deben comprender aquella idea detalladamente y mantenerla mientras se produce el software. Para esto, los especialistas pueden hacer uso del UML ya que les ayudará a capturar la idea del sistema requerido, para luego comunicarla a los involucrados en el proyecto. Esta tarea se lleva a cabo en las etapas de análisis y diseño, utilizando simbología y diagramas UML con el objeto de modelar el sistema. Modelar el sistema utilizando los diagramas de UML, significara en definitiva contar con documentos que plasman el trabajo de capturar la idea para la posterior evolución del proyecto. El cliente podrá entender el plan de trabajo de los especialistas y señalar cambios si no se captó

EDILBERTO GUTIERREZ PALACIOS

correctamente alguna necesidad; o bien, indicar cambios sobre la marcha del proyecto. A su vez, los especialistas encargados del desarrollo generalmente trabajaran en equipo, por lo que cada uno de ellos podrá identificar su trabajo particular y el general a partir de los diagramas UML. UML proporciona las herramientas para organizar un diseño sólido y claro, que comprendan los especialistas involucrados en las distintas etapas de la evolución del proyecto, y por qué no para documentar un anteproyecto que será entregado al cliente.

EDILBERTO GUTIERREZ PALACIOS

HISTORIA DE UML UML respaldado por el OMG (Object Management Group), es un lenguaje de modelado de sistemas de software. Diseñado como una herramienta gráfica donde se puede construir, especificar, visualizar y documentar sistemas. Permite representar el modelo de un escenario, donde se describen las entidades intervinientes y sus relaciones. También podemos al describir cada entidad, especificar las propiedades y el comportamientos de las mismas. Rational Software Corporation contrato en 1994 a James Rumbaugh y la compañíá se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: -

OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a

objetos. -

Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos.

Poco después se les une Ivar Jacobson, el creador del método de ingeniería de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a estos especialistas que desarrollaran un Lenguaje Unificado de Modelado abierto. Se organizó en 1996 un consorcio internacional llamado UML Partners, para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una

EDILBERTO GUTIERREZ PALACIOS

respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y istrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997. UML desde 1995, es un estándar aprobado por la ISO como ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2.

EDILBERTO GUTIERREZ PALACIOS

DIAGRAMAS DE UML

Casos de Uso       

Clases Objetos Statechart Actividades Secuencia Colaboración Componentes DIAGRAMA DE CLASES DE UML

Describe las clases y muestra las relaciones entre ellas. TIPOS DE RELACIONES: ▪

Is-a: una clase es del tipo de otra clase

▪

Asociaciones entre clases:

•

Una clase contiene a otra clase (Has-a)

–

Agregación

–

Composición

•

Una clase usa otra clase (Uses-a)

•

Una clase crea a otra clase REPRESENTACIÓN DE CLASES MiClase

EDILBERTO GUTIERREZ PALACIOS

MiClase

❖

La figura de la izquierda muestra el símbolo para una clase en su forma completa, y el de

la derecha en su forma abreviada. ❖

Por convención, los nombres de clases comienzan con mayúsculas y deben estar escritos

con letra de tipo bold en sus símbolos. REPRESENTACIÓN DE CLASES (II) MiClase

❖

En la forma completa del símbolo:

El compartimento superior está destinado al nombre de la clase. El compartimento del medio muestra los atributos de la clase. El compartimento inferior muestra las operaciones.

ATRIBUTOS Los atributos representan información acerca de un objeto.

EDILBERTO GUTIERREZ PALACIOS

El término atributo no es exactamente sinónimo de variable. Un atributo representa una propiedad definida en términos abstractos, mientras que una variable es el mecanismo de implementación del atributo.

ATRIBUTOS

Perso na nombre: String fechaDeNacimiento: date altura: float

Se ubican en el compartimento inferior de las clases. Perso na nombre: String fechaDeNacimiento: date altura:float

OPERACIONES

getNombre():String setNombre(nombre:String) ... getEdad():integer getAltura():float setAltura(altura:float)

OPERACIONES SOBRECARGADAS Las operaciones sobrecargadas aparecen varias Veces en el símbolo de la clase (en cada ocasión con diferente cantidad o tipo de argumentos). Una de las versiones de la operación rebajarPrecio reduce el precio del producto en una cantidad predeterminada y la otra recibe un porcentaje de descuento.

VISIBILIDAD DE ATRIBUTOS Y OPERACIONES UML añade un prefijo a las operaciones y atributos para indicar su visibilidad: + Para atributos y operaciones públicas.

EDILBERTO GUTIERREZ PALACIOS

# Para atributos y operaciones protegidas. - para atributos y operaciones privadas. Si se omite el prefijo, se asume que el atributo u operación es pública. ATRIBUTOS Y OPERACIONES DE CLASES Los atributos y operaciones de clase (aquellos que no pertenecen a una instancia en particular sino que son compartidos por toda la clase) se representan en UML subrayados. OrdenDeCompra - NumeroDeOrdenes: int ... + getNumeroDeOrdenes():int ...

Registra el número de órdenes de compra creadas Obtiene en número de órdenes de compra creadas. OPERACIONES Y CLASES ABSTRACTAS Políg ono area:float ... + getArea():float {abstract} ...

Políg ono area:float ... + getArea():float...

El nombre de una clase abstracta debe estar en estilo itálico o con la indicación {abstract}. Las operaciones abstractas también deben estar en estilo itálico o con la indicación {abstract}.

GENERALIZACIÓN: HERENCIA SIMPLE VehículoMotor

EDILBERTO GUTIERREZ PALACIOS

Automóvil

Camión

Una jerarquía de herencia se muestra utilizando flechas que apuntan hacia arriba en la jerarquía (en el ejemplo: Automóvil y Camión son subclases de VehículoMotorizado). GENERALIZACIÓN: HERENCIA SIMPLE (II) VehículoMotorizado

Automóvi

Camión

Otro estilo para mostrar una jerarquía de herencia. GENERALIZACIÓN: HERENCIA MÚLTIPLE UML permite mostrar herencia múltiple (cuando una clase hereda directamente de más de una superclase). ASOCIACIONES Una asociación caracteriza un cierto tipo de relación que puede darse entre instancias de determinadas clases. ❖Por ejemplo, si tenemos las clases Persona y Perro, las siguientes relaciones podrían darse entre sus instancias: ▪

Juan es propietario de Fido

▪

Pedro es propietario de Rintintín

▪

Pedro es propietario de Lassie

ASOCIACIONES (II)

Persona

propietari o 1..1

DePerr o

0. .* propie

Perro

EDILBERTO GUTIERREZ PALACIOS

La asociación muestra que existe una relación de propiedad entre personas y perros, por la cual una persona puede ser propietario de cero o más perros y un perro es propiedad de una única persona. ASOCIACIONES (III) Cada asociación se muestra como una línea entre dos clases. ❖ El nombre de la asociación aparece en la línea. ❖ El rol de cada clase en la asociación aparece al lado de la clase, al final de la línea. ❖ La multiplicidad de la asociación también aparece al final de la línea. MÁS SOBRE ASOCIACIONES ❖ No es obligatorio poner nombres a las asociaciones. Sin embargo es recomendable (se nombran con un sustantivo singular).

❖

No es necesario poner nombres de roles tampoco.

❖ La multiplicidad en un diagrama puede ser debatible, depende de lo que interese representar en el modelo.

❖ Puede existir más de una asociación entre un par de clases. Asimismo, una clase puede tener una asociación consigo misma. COMPOSICIÓN Permite expresar que un objeto se compone de otros objetos. COMPOSICIÓN (II) ❖ La asociación entre el objeto compuesto y sus constituyentes se denota con un una línea con diamante relleno en el extremo del objeto compuesto.

❖ El rol del constituyente aparece en el extremo del constituyente de la asociación (un objeto constituyente puede jugar más de un rol).

❖

Debe mostrarse la multiplicidad en el extremo del constituyente de la asociación.

EDILBERTO GUTIERREZ PALACIOS

COMPOSICIÓN (III)  El objeto compuesto no existe sin sus componentes.

 Un objeto constituyente puede formar parte de solo un objeto compuesto a la vez.  La composición suele ser heterogénea: los componentes suelen ser de distintas clases (cola, fuselaje, etc.).

AGREGACIÓN Permite expresar que un objeto agrupa a otros objetos. AGREGACIÓN (II) La asociación entre el agregado y sus constituyentes se denota con un una línea con diamante abierto (no relleno) en el extremo del agregado.

 El rol del constituyente aparece en el extremo del constituyente de la asociación.

 Debe mostrarse la multiplicidad en ambos extremos de la asociación. AGREGACIÓN (III) El objeto agregado puede existir potencialmente sin sus objetos constituyentes.

 Un objeto constituyente puede ser parte de más de uno agregado.

 La agregación tiende a ser homogénea: los objetos constituyentes son de la misma clase.

CREACIÓN Se pude representar la idea que una clase es creada por otra utilizando la etiqueta < >

DIAGRAMA DE OBJETOS DE UML

EDILBERTO GUTIERREZ PALACIOS

Muestran “fotografías” de los objetos pertenecientes a un sistema, en un momento determinado. Sirven, por ejemplo, para ejemplificar la configuración de objetos.