Informe Diagramas Uml

7/24/2019 Informe Diagramas Uml

1/13

DIAGRAMAS DE CLASES EN UML

PRESENTADO POR:

EDILBERTO GUTIRREZ PALACIOS

PRESENTADO A:

WILSON LANCHEROS LOPEZ

CORPORACION UNIFICADA DE EDUCACIN SUPERIOR CUN

FACULTAD DE INGENIERIA DE SISTEMAS

PROGRAMACIN ORIENTADA A OBJETOS

2015


2/13

EDILBERTO GUTIERREZ PALACIOS

IINTRODUCCIN

Generalizando al producirse cualquier requerimiento de un software, surgen ideas. Poniendo un

ejemplo un administrador general de un negocio que compra y vende productos, se observa que

utilizado la informtica puede mejorar sustancialmente su administracin. Entonces, teniendo

una idea bastante clara de su necesidad, acude a especialistas en desarrollo de software.

espu!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"

#. $elevamiento%. &nlisis

'. ise(o

). esarrollo

*. +apacitacin. -antenimiento

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 dic0o negocio y cmo interact1an. En definitiva, los

especialistas deben comprender aquella idea detalladamente y mantenerla mientras se produce el

software.

Para esto, los especialistas pueden 0acer uso del 2-3 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 anlisis y dise(o, utilizando simbolog4a y diagramas 2-3 con el objeto de

modelar el sistema.

-odelar el sistema utilizando los diagramas de 2-3, significara en definitiva contar con

documentos que plasman el trabajo de capturar la idea para la posterior evolucin del proyecto.

El cliente podr entender el plan de trabajo de los especialistas y se(alar cambios si no se capt


3/13


correctamente alguna necesidad5 o bien, indicar cambios sobre la marc0a del proyecto. & 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 2-3.

2-3 proporciona las 0erramientas para organizar un dise(o slido y claro, que comprendan los

especialistas involucrados en las distintas etapas de la evolucin del proyecto, y por qu! no para

documentar un anteproyecto que ser entregado al cliente.


4/13


HISTORIA DE UML

2-3 respaldado por el 6-G 6bject -anagement Group/, es un lenguaje de modelado de

sistemas de software. ise(ado como una 0erramienta grfica 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. 7ambi!n podemos al describir cada entidad, especificar las propiedades y el

comportamientos de las mismas.

$ational 8oftware +orporation contrato en #99) a :ames $umbaug0 y la compa(4 se convirti

en la fuente de los dos esquemas de modelado orientado a objetos ms populares de la !poca"

; 6-7 6bject;modeling tec0nique/ de $umbaug0, que era mejor para anlisis orientado a

objetos.

; -!todo


5/13


respuesta al 6-G $>P. El borrador de la especificacin 2-3 #.? de 2-3 Partners fue

propuesto a la 6-G en enero de #99@. urante el mismo mes la 2-3 Partners form una

>uerza de 7area 8emntica, encabezada por +ris Aobryn y administrada por Ed EyB0olt, para

finalizar las semnticas de la especificacin y para integrarla con otros esfuerzos de

estandarizacin. El resultado de este trabajo, el 2-3 #.#, fue presentado ante la 6-G en agosto

de #99@ y adoptado por la 6-G en noviembre de #99@.

2-3 desde #99*, es un estndar aprobado por la =86 como =86C=E+ #9*?#"%??* =nformation

tec0nology D 6pen istributed Processing D 2nified -odeling 3anguage 2-3/ ersion

#.).%.


6/13


DIAGRAMAS DE UML

C!"! #$ U!"

C%!$! O&'$("! S(($)*+( A)(,-,##$! S$).$/), C"%&"+),/ C""/$/($!

DIAGRAMA DE CLASES DE UML

escribe las clases y muestra las relaciones entre ellas.

TIPOS DE RELACIONES:

3 =s;a" una clase es del tipo de otra clase

F &sociaciones entre clases"

2na clase contiene a otra clase Has;a/

I &gregacin

I +omposicin

2na clase usa otra clase 2ses;a/

2na clase crea a otra clase

REPRESENTACIN DE CLASES

MiClase


7/13


M,C%!$

3a figura de la izquierda muestra el s4mbolo para una clase en su forma completa, y el de

la derec0a en su forma abreviada.

Por convencin, los nombres de clases comienzan con may1sculas y deben estar escritos

con letra de tipo bold en sus s4mbolos.

REPRESENTACIN DE CLASES 4II

M,C%!$

En la forma completa del s4mbolo"

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

3os atributos representan informacin acerca de un objeto.


8/13


El t!rmino atributo no es eJactamente sinnimo de variable. 2n atributo representa una

propiedad definida en t!rminos abstractos, mientras que una variable es el mecanismo de

implementacin del atributo.

&7$=


9/13


M Para atributos y operaciones protegidas.

; para atributos y operaciones privadas.

8i se omite el prefijo, se asume que el atributo u operacin es p1blica.

ATRIBUTOS 7 OPERACIONES DE CLASES

3os 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 2-3 subrayados.

O+#$/D$C"+

; Kumeroe6rdenes" int

...

L getKumeroe6rdenes/"int

$egistra el n1mero de rdenes de compra creadas

6btiene en n1mero de rdenes de compra creadas.

OPERACIONES 7 CLASES ABSTRACTAS

Polg

ono

Polg

ono

area"float

...area"float

...L get&rea/"float NabstractO

...L getArea():float...

El nombre de una clase abstracta debe estar en estilo itlico o con la indicacin NabstractO.

3as operaciones abstractas tambi!n deben estar en estilo itlico o con la indicacin NabstractO.

GENERALIZACIN: HERENCIA SIMPLE

6$*8).%"M"("+


10/13


2na jerarqu4a de 0erencia se muestra utilizando flec0as que apuntan 0acia arriba en la jerarqu4a

en el ejemplo" &utomvil y +amin son subclases de e04culo-otorizado/.

GENERALIZACIN: HERENCIA SIMPLE 4II

6$*8).%"M"("+,9#"

A.("-, C,/

6tro estilo para mostrar una jerarqu4a de 0erencia.

GENERALIZACIN: HERENCIA MLTIPLE

2-3 permite mostrar 0erencia m1ltiple cuando una clase 0ereda directamente de ms de una

superclase/.

ASOCIACIONES

2na asociacin caracteriza un cierto tipo de relacin que puede darse entre instancias dedeterminadas clases.

Por ejemplo, si tenemos las clases Persona y Perro, las siguientes relaciones podr4an darse

entre sus instancias"

F :uan es propietario de >ido

F Pedro es propietario de $intint4n

F Pedro es propietario de 3assie

ASOCIACIONES 4II

P$+!"/prop etar ePerr ?. P$++"#..# ro ie

CaminAutomvil


11/13


3a asociacin muestra que eJiste una relacin de propiedad entre personas y perros, por la cual

una persona puede ser propietario de cero o ms perros y un perro es propiedad de una 1nica

persona.

ASOCIACIONES 4III

+ada asociacin se muestra como una l4nea entre dos clases.

El nombre de la asociacin aparece en la l4nea.

El rol de cada clase en la asociacin aparece al lado de la clase, al final de la l4nea.

3a multiplicidad de la asociacin tambi!n aparece al final de la l4nea.

M;S SOBRE ASOCIACIONES

Ko es obligatorio poner nombres a las asociaciones. 8in embargo es recomendable se

nombran con un sustantivo singular/.

Ko es necesario poner nombres de roles tampoco.

3a multiplicidad en un diagrama puede ser debatible, depende de lo que interese

representar en el modelo.

Puede eJistir ms de una asociacin entre un par de clases. &simismo, una clase puedetener una asociacin consigo misma.

COMPOSICIN

Permite eJpresar que un objeto se compone de otros objetos.

COMPOSICIN 4II

3a asociacin entre el objeto compuesto y sus constituyentes se denota con un una l4nea

con diamante relleno en el eJtremo del objeto compuesto.

El rol del constituyente aparece en el eJtremo del constituyente de la asociacin un

objeto constituyente puede jugar ms de un rol/.

ebe mostrarse la multiplicidad en el eJtremo del constituyente de la asociacin.


12/13


COMPOSICIN 4III

El objeto compuesto no eJiste sin sus componentes.

2n objeto constituyente puede formar parte de solo un objeto compuesto a la vez.

3a composicin suele ser 0eterog!nea" los componentes suelen ser de distintas clases

cola, fuselaje, etc./.

AGREGACIN

Permite eJpresar que un objeto agrupa a otros objetos.

AGREGACIN 4II

3a asociacin entre el agregado y sus constituyentes se denota con un una l4nea con diamanteabierto no relleno/ en el eJtremo del agregado.

El rol del constituyente aparece en el eJtremo del constituyente de la asociacin.

ebe mostrarse la multiplicidad en ambos eJtremos de la asociacin.

AGREGACIN 4III

El objeto agregado puede eJistir potencialmente sin sus objetos constituyentes.

2n objeto constituyente puede ser parte de ms de uno agregado.

3a agregacin tiende a ser 0omog!nea" los objetos constituyentes son de la misma clase.

CREACIN

8e pude representar la idea que una clase es creada por otra utilizando la etiqueta QQcreateRR

DIAGRAMA DE OBJETOS DE UML


13/13


-uestran Sfotograf4asT de los objetos pertenecientes a un sistema, en un momento determinado.

8irven, por ejemplo, para ejemplificar la configuracin de objetos.

Informe Diagramas Uml

Documents

Transcript of Informe Diagramas Uml