Diagramas de clases

DIAGRAMAS DE CLASES

Historia:
El lenguaje UML comenz a gestarse en octubre de 1994, cuando Rumbaugh se uni a la compa a Rational !undada por "ooch #dos reputados in$estigadores en el %rea de metodolog a del so!t&are'( El objeti$o de ambos era uni!icar dos m)todos *ue hab an desarrollado+ el m)todo "ooch , el -M. #-bject Modelling .ool '( El primer borrador apareci en octubre de 199/( En esa misma )poca otro reputado in$estigador, 0acobson, se uni a Rational , se inclu,eron ideas su,as( Estas tres personas son conocidas como los 1tres amigos2( 3dem%s, este lenguaje se abri a la colaboracin de otras empresas para *ue aportaran sus ideas( .odas estas colaboraciones condujeron a la de!inicin de la primera $ersin de UML(

Objetivos
4roporcionar las sem%nticas su!icientes para alcanzar aspectos del modelado *ue son de esperar en un !uturo, como por ejemplo aspectos relacionados con la tecnolog a de componentes, el cmputo distribuido, etc( 4roporcionar mecanismos de e5tensin de !orma *ue pro,ectos concretos puedan e5tender el meta6modelo a un coste bajo( 4roporcionar mecanismos de e5tensin de !orma *ue apro5imaciones de modelado !uturas podr an desarrollarse encima del UML( 4ermitir el intercambio del modelos entre una gran $ariedad de herramientas( 4roporcionar sem%nticas su!icientes para especi!icar las inter!aces a bibliotecas para la comparicin , el almacenamiento de componentes del modelo( 7urante el desarrollo del UML sus autores tu$ieron en cuenta+ 4roporcionar una notacin , sem%nticas su!icientes para poder alcanzar una gran cantidad de aspectos del modelado contempor%neo de una !orma directa , econmica(

Diferentes tipos de Diagramas

INGENIERA DE SOFTWARE Pgina 1

Diagramas de clases

Los diagramas se utilizan para representar di!erentes perspecti$as de un sistema de !orma *ue un diagrama es una pro,eccin del mismo( UML proporciona un amplio conjunto de diagramas *ue normalmente se usan en pe*ueos subconjuntos para poder representar las cinco $istas principales de la ar*uitectura de un sistema( Diagramas de Clases Muestran un conjunto de clases, inter!aces , colaboraciones, as como sus relaciones( Estos diagramas son los m%s comunes en el modelado de sistemas orientados a objetos , cubren la $ista de diseo est%tica o la $ista de procesos est%tica #s inclu,en clases acti$as'( Diagramas de Objetos Muestran un conjunto de objetos , sus relaciones, son como !otos instant%neas de los diagramas de clases , cubren la $ista de diseo est%tica o la $ista de procesos est%tica desde la perspecti$a de casos reales o protot picos( Diagramas de Casos de sos Muestran un conjunto de casos de uso , actores #tipo especial de clases' , sus relaciones( 8ubren la $ista est%tica de los casos de uso , son especialmente importantes para el modelado , organizacin del comportamiento( Diagramas de Se!"en!ia # de Colabora!i$n .anto los diagramas de secuencia como los diagramas de colaboracin son un tipo de diagramas de interaccin( 8onstan de un conjunto de objetos , sus relaciones, inclu,endo los mensajes *ue se pueden en$iar unos objetos a otros( 8ubren la $ista din%mica del sistema( Los diagramas de secuencia en!atizan el ordenamiento temporal de los mensajes mientras *ue los diagramas de colaboracin muestran la organizacin estructural de los objetos *ue en$ an , reciben mensajes( Los diagramas de secuencia se pueden con$ertir en diagramas de colaboracin sin
INGENIERA DE SOFTWARE Pgina 9

Diagramas de clases
perdida de in!ormacin, lo mismo ocurren en sentido opuesto( Diagramas de Estados Muestran una ma*uina de estados compuesta por estados, transiciones, e$entos , acti$idades( Estos diagramas cubren la $ista din%mica de un sistema , son mu, importantes a la hora de modelar el comportamiento de una inter!az, clase o colaboracin( Diagramas de A!tividades :on un tipo especial de diagramas de estados *ue se centra en mostrar el !lujo de acti$idades dentro de un sistema( Los diagramas de acti$idades cubren la parte din%mica de un sistema , se utilizan para modelar el !uncionamiento de un sistema resaltando el !lujo de control entre objetos(

%ipos de diagramas:
INGENIERA DE SOFTWARE Pgina ;

Diagramas de clases

7iagramas de estructura+ mostrar la estructura est%tica del sistema *ue se est% modelando <nclu,e+ diagramas de clase, componentes ,=o objetos( 7iagramas de comportamiento+ muestra el comportamiento din%mico entre los objetos , el sistema( <nclu,e+ diagramas de acti$idades, casos de uso , de secuencia Atrib"tos :on descripciones de caracter sticas, se usan para modelar in!ormacin asociada con una entidad, sinta5is+ >ombre atributo ?multiplicidad@+.ipo A Balor inicial La multiplicidad es opcional e indica el nCmero de atributos por instancia de la clase& Clases Las clases son descripciones de un juego de objetos con caracter sticas, comportamiento, relaciones , sem%nticas comunes( :e usan para modelar un juego de conceptos o entidades( :e denotan con un rect%ngulo con compartimentos( En ellos se ponen el nombre, los atributos, las operaciones , adem%s se pueden usar para anotar otras propiedades del modelo como son #reglas del negocio, responsabilidades, e5cepciones, etc(' 4ueden tener inter!aces para especi!icar conjuntos de operaciones proporcionadas a su ambiente( .odas las operaciones deben estar asociadas a m)todos( 4ueden tener relaciones de generalizacin con otras clases(

INGENIERA DE SOFTWARE

Pgina 4

Diagramas de clases

'C"(les son s"s "sos m(s !om"nes) Modelar la $ista de diseo est%tica de un sistema+ 4ara modelar el $ocabulario de un sistema( <mplica decidir *ue abstracciones son parte del sistema , cuales no , as especi!icar esas abstracciones , sus responsabilidades( 4ara modelar colaboraciones simples( :e emplean para $isualizar un conjunto de datos , sus colaboraciones( 4ara modelar un es*uema lgico de base de datos( :e necesitar% almacenar in!ormacin persistente en una base de datos relacional o en una base de datos orientada a objetos( Una colaboracin es un conjunto de clases, inter!aces , otros elementos *ue colaboran para proporcionar un comportamiento cooperati$o ma,or *ue la suma de todos los elementos
INGENIERA DE SOFTWARE Pgina /

Diagramas de clases
'C"(les son las t*!ni!as !om"nes de modelado) Las clases colaboran unas con otras para llegar a una sem%ntica ma,or *ue la asociada a cada clase indi$idual, por lo *ue a parte de capturar el $ocabulario del sistema ha, *ue prestar atencin a la $isualizacin, especi!icacin, construccin , documentacin de la !orma en *ue estos elementos del $ocabulario colaboran entre s ( 4ara modelar una colaboracin+ Da, *ue identi!icar los mecanismos *ue se *uieren modelar( Da, *ue identi!icar las clases, inter!aces , otras colaboraciones *ue participan en esta colaboracin, , las relaciones entre estos elementos( Da, *ue usar escenarios para recorrer la interaccin entre estos elementos( :e descubrir%n partes del model *ue !altaban , otras *ue eran sem%nticamente incorrectas( Rellenar estos elementos con su contenido( 4ara las clases se realiza un reparto e*uilibrado de responsabilidades( 7espu)s, ha, *ue con$ertir estas en atributos , operaciones concretos( 'C$mo se modela "n es+"ema l$gi!o de base de datos) 8uando se modela con diagramas de clases se permite el modelado del comportamiento de los datos a almacenar( 4ara modelar un es*uema+ Da, *ue identi!icar a*uellas clases del modelo cu,o estado debe trascender el tiempo de $ida de las aplicaciones( Da, *ue crear un diagrama de clases *ue contenga estas clases( Da, *ue e5pandir los detalles estructurales de estas clases( Es especi!icar los detalles de sus atributos( "uscar patrones comunes *ue complican el diseo ! sico de bases de datos #asociaciones c clicas , uno a uno'( :e deben crear abstraccione intermedias para simpli!icar la estructura lgica( Da, *ue considerar el comportamiento de las clases persistentes e5pandiendo las operaciones *ue sean importantes para el acceso a los datos , la integridad de estos( Da, *ue usar herramientas *ue a,uden a trans!ormar un diseo lgico en un diseo ! sico(

Un diagrama de !lases es un tipo de diagrama est%tico *ue describe la estructura de un sistema mostrando sus clases, orientados a objetos(

4ropiedad de objetos *ue tienen propiedades ,=u operaciones *ue contienen un conte5to , un dominio, los primeros dos ejemplos son clases de datos , el tercero clase de lgica de negocio, dependiendo
Pgina E

INGENIERA DE SOFTWARE

Diagramas de clases
de *ui)n disee el sistema se pueden unir los datos con las operaciones(

El diagrama de clases inclu,e mucha m%s in!ormacin como la relacin entre un objeto , otro, la herencia de propiedades de otro objeto, conjuntos de operaciones=propiedades *ue son implementadas para una inter!az gr%!ica( 4resenta las clases del sistema con sus relaciones estructurales , de herencia(

Las clases representan los blo*ues de construccin m%s importantes de cual*uier sistema orientado a objetos( Una clase es una descripcin de un conjunto de objetos *ue comparten los mismos atributos, operaciones, relaciones , sem%ntica( La representacin gr%!ica de clases en UML se muestra en la siguiente !igura(

Esta notacin es independiente de cual*uier lenguaje de programacin( El primer blo*ue de la !igura representa el nombre de la clase, el segundo blo*ue contiene los atributos, , el tercer blo*ue contiene las operaciones( El nombre de la clase puede ser simple #ej+ Figura' o puede indicar el camino completo #pa*uete' donde reside la clase #ej+ Gra!ico++Figura'( En la de!inicin de los atributos se pueden incluir sus tipos #ej+ altura+Real'( Lo mismo para las operaciones #ej+ mo$er#a+int, b+int'+boolean'( >o es necesario mostrar todas las caracter sticas( 3 $eces las clases tienen tantas caracter sticas, *ue no es con$eniente mostrarlas todas( En estos casos tambi)n se pueden organizar las caracter sticas usando estereotipos( 4or ejemplo+

INGENIERA DE SOFTWARE

Pgina H

Diagramas de clases

Responsabilidades Una responsabilidad es un contrato o una obligacin de una clase( 3l modelar clases, un buen comienzo consiste en especi!icar las responsabilidades de los elementos( Una clase bien estructurada tiene al menos una responsabilidad #deber a tener pocas'( Gr%!icamente, las responsabilidades se e5presan en una seccin al !inal de la clase( 4or ejemplo+

so de !lases Modelar el vo!ab"lario de "n sistema: 4ara modelar el $ocabulario de un sistema, ha, *ue identi!icar a*uellas cosas *ue utilizan los usuarios para describir el problema o la solucin( 4ara esto se pueden utilizar tarjetas 8R8 , an%lisis basado en casos de uso( Una $ez identi!icadas las
INGENIERA DE SOFTWARE Pgina I

Diagramas de clases
abstracciones, ha, *ue identi!icar sus responsabilidades( El siguiente es un ejemplo del modelado del $ocabulario de un sistema(

Modelar la distrib"!i$n de responsabilidades: 4ara modelar la distrubucin de responsabilidades en un sistema, ha, *ue identi!icar un conjunto de clases *ue colaboren entre ellas para lle$ar a cabo algCn comportamiento( Luego ha, *ue identi!icar el conjunto de responsabilidades para cada clase( 4or ejemplo+

INGENIERA DE SOFTWARE

Pgina 9

Diagramas de clases

-bser$e cmo estas clases colaboran de !orma *ue ninguna clase hace mucho ni mu, poco( Rela!iones Las clases casi nunca se encuentran aisladas( 4or lo general la ma,or a de ellas colaboran con otras de $arias maneras( 4or tanto, al modelar un sistema tambi)n ha, *ue modelar la !orma en *ue las clases se relacionan( En el modelado orientado a objetos ha, tres tipos de relaciones+ dependencias, generalizaciones , asociaciones(

Una dependencia es una relacin de uso, *ue declara *ue un cambio en la especi!icacin de un elemento #por ejemplo la clase E$ento' puede a!ectar a otro elemento *ue la utiliza #por ejemplo la clase Bentana', pero no necesariamente a la in$ersa #la !lecha $a dirigida hacia el elemento del cual se depende'( Una dependencia *uiere decir *ue un elemento utiliza a otro( Una generalizacin conecta una clase general #llamada superclase o padre' con otra clase m%s especializada #llamada subclase o hijo'( Es una relacin Jes-unJ o Jes-unaJ( 4or ejemplo, el 8uadro7ialogo es una Bentana( Las asociaciones son relaciones estructurales entre instancias, *ue especi!ican *ue los objetos de un elemento est%n conectados con los objetos de otro( Es legal *ue los objetos de unas clases est)n conectados con objetos de la misma clase( Da, cuatro tipos de JadornosJ *ue se le
INGENIERA DE SOFTWARE Pgina 1K

Diagramas de clases
pueden poner a estas relaciones+ nombre, rol, multiplicidad , agregacin( Ejemplo+

,ombre: Una asociacin puede tener un nombre, *ue se utiliza para describir la naturaleza de la relacin( 4ara e$itar ambigLedades, se puede indicar una direccin al nombre, es decir, la direccin en *ue se debe leer el nombre( Rol: Un rol es la cara *ue la clase de un e5tremo de la asociacin presenta a la clase del otro e5tremo( Es el rol *ue juega la clase en la asociacin( M"ltipli!idad: Representa el nCmero de objetos *ue pueden conectarse a tra$)s de una relacin de asociacin( :e puede indicar una multiplicidad de e5actamente uno #1', cero o uno #K((1', muchos #K((M', o uno o m%s #1((M'( .ambi)n se puede indicar un $alor e5acto #por ejemplo, ;'( Agrega!i$n: 3 $eces se desea modelar una relacin de tipo Jtodo=parteJ, en la cual una clase representa algo grande #el todo', *ue consta de elementos m%s pe*ueos #las partes'( Este tipo de relacin se denomina agregacin, , es una relacin Jtiene-unJ o Jtiene-unaJ( Ejemplo+

Composi!i$n: La composicin es un tipo especial de asociacin, *ue tambi)n modela relaciones Jtodo=parteJ( La di!erencia es *ue tiene una !uerte relacin de pertenencia , $idas coincidentes de la parte con el todo( Las JpartesJ pueden crearse despu)s del JtodoJ, pero una $ez creadas, $i$en , mueren con el JtodoJ #se pueden eliminar e5pl citamente antes'( Nuiere decir *ue una JparteJ, solamente puede estar relacionada con un JtodoJ( Ejemplo+
INGENIERA DE SOFTWARE Pgina 11

Diagramas de clases

En el siguiente ejemplo se muestran algunas de la relaciones antes descritas( -bser$en el poder de e5presin de esta notacin(

Alg"nos !on!eptos 4ara di!erenciar a las clases abstractas, el nombre de )stas se pone en cursi$a( Las clases abstractas no pueden tener instancias directas( La visibilidad de una caracter stica especi!ica si puede ser utilizada por otros objetos( Da, tres ni$eles de $isibilidad en UML+ public #cual*uiera la puede usar, la caracter stica es precedida por el s mbolo O', protected #cual*uier descendiente la puede utilizar, se especi!ica con el s mbolo P', , pri$ate #solamente la propia clase la usa, se especi!ica con el s mbolo 6'( El alcance de una caracter stica de!ine si la caracter stica aparece en cada instancia de la clase, o si slo ha, una caracter stica para todas las instancias( 4ara de!inir alcance de clase, las caracter sticas se subra,an(
INGENIERA DE SOFTWARE Pgina 19

Diagramas de clases
4or de!ecto, las caracter sticas tienen alcance de instancia( Ejemplo+

Da, otras propiedades poco utilizadas( 4or ejemplo, lea!, *ue indica *ue una clase es una hoja, , por tanto no permite *ue otras clases herenden caracter sticas de ella( La propiedad root indica *ue una clase no puede tener padres( 4or ejemplo+

La multiplicidad de!ine el nCmero de instancias *ue puede tener una clase( Esta es K, 1 o n( 4or de!ecto, las clases tienen multiplicidad n( :i se *uiere
INGENIERA DE SOFTWARE Pgina 1;

Diagramas de clases
de!inir una multiplicidad di!erente de n, ha, *ue especi!icarla( 4or ejemplo+

Esto *uiere decir *ue la clase 8ontrolador Red solamente puede tener una instancia( 3 su $ez, para esta clase pueden haber dos o m%s puerto 8onsola(

E-EM.LOS DE DIAGRAMAS DE CLASES:

INGENIERA DE SOFTWARE

Pgina 14

Diagramas de clases

INGENIERA DE SOFTWARE

Pgina 1/

Diagramas de clases

INGENIERA DE SOFTWARE

Pgina 1E