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 metodologa del so!t&are'( El objeti$o de ambos era uni!icar dos m)todos *ue haban 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 inclueron ideas suas( Estas tres personas son conocidas como los tres amigos2( 3dem%s, este lenguaje se abrió a la colaboración de otras empresas para *ue aportaran sus ideas( .odas estas colaboraciones condujeron a la de!inición de la primera $ersión de UML(
Objetivos roporcionar las sem%nticas su!icientes para alcanzar aspectos del modelado *ue son de esperar en un !uturo, como por ejemplo aspectos relacionados con la tecnologa de componentes, el cómputo distribuido, etc( roporcionar mecanismos de e5tensión de !orma *ue proectos concretos puedan e5tender el meta6modelo a un coste bajo( roporcionar mecanismos de e5tensión de !orma *ue apro5imaciones de modelado !uturas podran desarrollarse encima del UML( ermitir el intercambio del modelos entre una gran $ariedad de herramientas( roporcionar sem%nticas su!icientes para especi!icar las inter!aces a bibliotecas para la comparición el almacenamiento almacenamien to de componentes del modelo( 7urante el desarrollo del UML sus autores tu$ieron en cuenta+ roporcionar una notación sem%nticas su!icientes para poder alcanzar una gran cantidad de aspectos del modelado contempor%neo de una !orma directa económica(
Diferentes tipos de Diagramas INGENIERÍA DE SOFTWARE
Página 1
Diagramas de clases
Los diagramas se utilizan para representar di!erentes perspecti$as de un sistema de !orma *ue un diagrama es una proección del mismo( UML proporciona un amplio conjunto de diagramas *ue normalmente se usan en pe*ueños 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 diseño est%tica o la $ista de procesos est%tica #s incluen 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 diseño est%tica o la $ista de procesos est%tica desde la perspecti$a de casos reales o prototpicos( 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 organización del comportamiento( Diagramas de Se!"en!ia # de Colabora!i$n .anto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción( 8onstan de un conjunto de objetos sus relaciones, incluendo 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 colaboración muestran la organización estructural de los objetos *ue en$an reciben mensajes( Los diagramas de secuencia se pueden con$ertir en diagramas de colaboración sin INGENIERÍA DE SOFTWARE
Página
Diagramas de clases perdida de in!ormación, 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 colaboración( 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: INGENIERÍA DE SOFTWARE
Página ;
Diagramas de clases
•
7iagramas de estructura+ mostrar la estructura est%tica del sistema *ue se est% modelando
•
7iagramas de comportamiento+ muestra el comportamiento din%mico entre los objetos el sistema(
Atrib"tos •
:on descripciones de caractersticas, se usan para modelar in!ormación 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 caractersticas, 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(' ueden tener inter!aces para especi!icar conjuntos de operaciones proporcionadas a su ambiente( .odas las operaciones deben estar asociadas a m)todos( ueden tener relaciones de generalización con otras clases(
INGENIERÍA DE SOFTWARE
Página 4
Diagramas de clases
'C"(les son s"s "sos m(s !om"nes) Modelar la $ista de diseño est%tica de un sistema+ ara modelar el $ocabulario de un sistema(
Página /
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 maor *ue la asociada a cada clase indi$idual, por lo *ue a parte de capturar el $ocabulario del sistema ha *ue prestar atención a la $isualización, especi!icación, construcción documentación de la !orma en *ue estos elementos del $ocabulario colaboran entre s( ara modelar una colaboración+ Da *ue identi!icar los mecanismos *ue se *uieren modelar( Da *ue identi!icar las clases, inter!aces otras colaboraciones *ue participan en esta colaboración, las relaciones entre estos elementos( Da *ue usar escenarios para recorrer la interacción entre estos elementos( :e descubrir%n partes del model *ue !altaban otras *ue eran sem%nticamente incorrectas( Rellenar estos elementos con su contenido( ara 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( ara modelar un es*uema+ Da *ue identi!icar a*uellas clases del modelo cuo 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 diseño !sico de bases de datos #asociaciones cclicas uno a uno'( :e deben crear abstraccione intermedias para simpli!icar la estructura lógica( 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 auden a trans!ormar un diseño lógico en un diseño !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(
•
ropiedad 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 lógica de negocio, dependiendo
INGENIERÍA DE SOFTWARE
Página
Diagramas de clases de *ui)n diseñe el sistema se pueden unir los datos con las operaciones( •
•
El diagrama de clases inclue mucha m%s in!ormación como la relación entre un objeto otro, la herencia de propiedades de otro objeto, conjuntos de operaciones=propiedades *ue son implementadas para una inter!az gr%!ica( resenta las clases del sistema con sus relaciones estructurales de herencia(
Las clases representan los blo*ues de construcción m%s importantes de cual*uier sistema orientado a objetos( Una clase es una descripción de un conjunto de objetos *ue comparten los mismos atributos, operaciones, relaciones sem%ntica( La representación gr%!ica de clases en UML se muestra en la siguiente !igura(
Esta notación es independiente de cual*uier lenguaje de programación( 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!inición 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 caractersticas( 3 $eces las clases tienen tantas caractersticas, *ue no es con$eniente mostrarlas todas( En estos casos tambi)n se pueden organizar las caractersticas usando estereotipos( or ejemplo+
INGENIERÍA DE SOFTWARE
Página H
Diagramas de clases
Responsabilidades Una responsabilidad es un contrato o una obligación 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 #debera tener pocas'( Gr%!icamente, las responsabilidades se e5presan en una sección al !inal de la clase( or ejemplo+
so de !lases Modelar el vo!ab"lario de "n sistema: ara modelar el $ocabulario de un sistema, ha *ue identi!icar a*uellas cosas *ue utilizan los usuarios para describir el problema o la solución( ara esto se pueden utilizar tarjetas 8R8 an%lisis basado en casos de uso( Una $ez identi!icadas las INGENIERÍA DE SOFTWARE
Página 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: ara modelar la distrubución 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( or ejemplo+
INGENIERÍA DE SOFTWARE
Página 9
Diagramas de clases
-bser$e cómo estas clases colaboran de !orma *ue ninguna clase hace mucho ni mu poco( Rela!iones Las clases casi nunca se encuentran aisladas( or lo general la maora de ellas colaboran con otras de $arias maneras( or 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 relación de uso, *ue declara *ue un cambio en la especi!icación 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 generalización conecta una clase general #llamada superclase o padre' con otra clase m%s especializada #llamada subclase o hijo'( Es una relación Jes-unJ o Jes-unaJ( or 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 INGENIERÍA DE SOFTWARE
Página 1K
Diagramas de clases pueden poner a estas relaciones+ nombre, rol, multiplicidad agregación( Ejemplo+
,ombre: Una asociación puede tener un nombre, *ue se utiliza para describir la naturaleza de la relación( ara e$itar ambigedades, se puede indicar una dirección al nombre, es decir, la dirección en *ue se debe leer el nombre( Rol: Un rol es la cara *ue la clase de un e5tremo de la asociación presenta a la clase del otro e5tremo( Es el rol *ue juega la clase en la asociación( M"ltipli!idad: Representa el nCmero de objetos *ue pueden conectarse a tra$)s de una relación de asociación( :e puede indicar una multiplicidad de e5actamente uno #1', cero o uno #K((1', muchos #K((', o uno o m%s #1(('( .ambi)n se puede indicar un $alor e5acto #por ejemplo, ;'( Agrega!i$n: 3 $eces se desea modelar una relación de tipo Jtodo=parteJ, en la cual una clase representa algo grande #el todo', *ue consta de elementos m%s pe*ueños #las partes'( Este tipo de relación se denomina agregación, es una relación J tiene-unJ o Jtiene-unaJ( Ejemplo+
Composi!i$n: La composición es un tipo especial de asociación, *ue tambi)n modela relaciones Jtodo=parteJ( La di!erencia es *ue tiene una !uerte relación 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 e5plcitamente antes'( Nuiere decir *ue una JparteJ, solamente puede estar relacionada con un JtodoJ( Ejemplo+ INGENIERÍA DE SOFTWARE
Página 11
Diagramas de clases
En el siguiente ejemplo se muestran algunas de la relaciones antes descritas( -bser$en el poder de e5presión de esta notación(
Alg"nos !on!eptos ara 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 caracterstica especi!ica si puede ser utilizada por otros objetos( Da tres ni$eles de $isibilidad en UML+ public #cual*uiera la puede usar, la caracterstica es precedida por el smbolo O', protected #cual*uier descendiente la puede utilizar, se especi!ica con el smbolo P', pri$ate #solamente la propia clase la usa, se especi!ica con el smbolo 6'( El alcance de una caracterstica de!ine si la caracterstica aparece en cada instancia de la clase, o si sólo ha una caracterstica para todas las instancias( ara de!inir alcance de clase, las caractersticas se subraan( INGENIERÍA DE SOFTWARE
Página 1
Diagramas de clases or de!ecto, las caractersticas tienen alcance de instancia( Ejemplo+
Da otras propiedades poco utilizadas( or ejemplo, lea!, *ue indica *ue una clase es una hoja, por tanto no permite *ue otras clases herenden caractersticas de ella( La propiedad root indica *ue una clase no puede tener padres( or ejemplo+
La multiplicidad de!ine el nCmero de instancias *ue puede tener una clase( Esta es K, 1 o n( or de!ecto, las clases tienen multiplicidad n( :i se *uiere INGENIERÍA DE SOFTWARE
Página 1;
Diagramas de clases de!inir una multiplicidad di!erente de n, ha *ue especi!icarla( or 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:
INGENIERÍA DE SOFTWARE
Página 14
Diagramas de clases
INGENIERÍA DE SOFTWARE
Página 1/
Diagramas de clases
INGENIERÍA DE SOFTWARE
Página 1