UMLcurso

Lenguaje
Unificado de
Modelaje
07/04/2005 Lic. Daniel Rubén Fernández Iriart 1
r.f.iriart@mercadototal.com
UML es un lenguaje para Visualizar......
La comunicación de modelos conceptuales sólo son precisos
siempre y cuando todos hablen el mismo lenguaje.
¾Muchas veces, ciertas cosas, en cuanto de sistemas de

software se trate,, es muy difícil entender, si no expresamos
modelos.
¾Un modelo explicita lo que queremos expresar

UML es un lenguaje para especificar.....
Ya que UML, desarrolla una sintaxis y una semántica muy
amplia, facilita que los modelos realizados sean precisos y no
ambiguos y completos
Agregacion: Auna fuerte

Dependencia: cuando una clase, forma de asociación donde la
(cliente), depende de otra clase,(server), relación está entre el “todo” y
para cumplimentar un servicio particular.sus “partes”.
Composicion
UML es un lenguaje para construir.....
Cue nt a
Permite la ingeniería directa e inversa +

+
o b te n e r S a ld o ( )
+a c e p ta r D e p o s ito s ( )
+ e xtr a e r D in e r o ( )
+ tr a n s fe r ir E n tr e C u e n ta s ( )
Tr a n s a c c io n
D e p o s it o Tr a n s f e r e n c ia Ext r a c c io n S a ld o
package PaqueteFinanciero;
/** @modelguid {93AD2C96-D10F-4691-B73A-
025F780E5404} */
public class Extraccion
07/04/2005 Lic. Danielextends Transaccion { 5
Rubén Fernández Iriart
} r.f.iriart@mercadototal.com
UML es un lenguaje para documentar.....
Use-Case Diagram Class Diagram State Diagram add file
DocumentList
FileMgr Document
add( )
name : int
fetchDoc( ) delete( )
docid : int
sortByName( ) numField : int
Writing
add file [ numberOffile==MAX ] /
get( ) flag OFF
open( ) read() fill the
close( ) code..
FileList read( )
sortFileList( ) Openning
Use Case 1 add( )

fList create( )
fillDocument( )
delete( )
1 close file
Actor A Actor B
close file
Closing
Reading
rep
Use Case 2 File
<<entity>>
Repository
(from Persistence)
read( )
GrpFile
Customer
name
name : char * = 0
readDoc( ) read( )
addr
readFile( ) open( )
create( )
receive()
fillFile( )
Use Case 3 withdraw()

Domain fetch()
send()
Deployment
Expert
UI
MFC Class Diagram

DocumentApp
ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼-¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö
DocumentList
RogueWave
Persistence
Repository Window95
Windows95
9: sortByName ( ) Windows95
global
¹®¼-°ü¸®
FileManager Å¬¶óÀÌ¾ðÆ®.EXE
¹®¼-°ü¸® ¾ÖÇÃ¸´
Definition mainWnd : MainWnd Windows
Package
NT
1: Doc view request ( ) L
Document
User Interface
Solaris
2: fetchDoc( )
¹®¼-°ü¸® ¿£Áø.EXE
4: create ( ) gFile : GrpFile
Diagram
Alpha
8: fillFile ( ) UNIX
ÀÀ¿ë¼-¹ö.EXE
Windows
NT
user : »ç¿ëÀÚ GraphicFile IBM
fileMgr : FileMgr
Mainframe
3: create ( )
File FileList
6: fillDocument ( )
µ¥ÀÌÅ¸º£ÀÌ½º¼-¹ö
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
Component
Collaboration Diagram Forward Engineering (Code Generation)
Diagram
and
user
mainWnd fileMgr :
FileMgr
document :
Document
gFile repository Reverse Engineering
Edición código fuente, compilación, debug y link
Æ¯Á¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )
»ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
È-ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â 6: fillDocument ( )

¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼-
°´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.
7: readFile ( )
8: fillFile ( )
È-¸é °´Ã¼´Â ÀÐ¾îµéÀÎ 9: sortByName ( )

°´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡
º¸¿©ÁØ´Ù.
Sequence Diagram
Sistema Ejecutable
4 mas 1
La
Modelo
visualición
de
de distintos prueba
Verificado
Modelo de modelos por:
Especificado
análisis por:
Implementado
por:
Modelo de casos
Modelo de
de uso
implementación
Distribuído por:
Realizado por:
Modelo
de diseño
Modelo de
despliegue
Especificado por
Modelo de
Casos de Uso Realizado por
Distribuído por
Modelo de Análisis
Implementado por
Modelo de Diseño
Verificado por
Modelo de
Despliegue
Modelo de
Implementación

Modelo de Pruebas
Reglas de UML
Reglas. Las reglas de UML son reglas semánticas
Nombres Æ Cómo llamar a los elementos, relaciones y diagramas.
Alcance Æ El contexto que da un significado específico a un nombre.
VisibilidadÆ Cómo se pueden ver y utilizar esos nombres por otros.
IntegridadÆ Cómo se relacionan apropiada y consistentemente unos

elementos con otros.
Ejecución Æ Qué significa ejecutar o simular un modelo dinámico.
Un ¨modelo bien formado¨, es aquél que es semánticamente

autoconsistente y está en armonía con todos sus modelos
relacionados

Mecanismos comunes o de extensividad
Especificaciones: proporciona una explicación textual de la sintaxis
y semántica de un bloque de construcción.
Ej. Un icono Clase expresa un conjunto completo de atributos,
operaciones, y comportamiento de la clase. Se usa para enunciar los
detalles de la clase o sistema.
Cue nta
Imostrarse
Adornos y estereotipos: la notación de un elemento expresa
detalles sobre ese elemento, y estos detalles son los adornos...Ej. Si
una clase es abstracta, la visibilidad de sus atributos o operaciones,
etc.
A s iento
<<abstracta>>
origen : char SerHumano
tam año : char
dormir() Us uario SerHu mano
asignarse() comer()
r.f.iriart@mercadototal.com dorm ir ()
Mecanismos de extensividad.
Permiten configurar y extender UML, para las
necesidades de un proyecto.
Estereotipos: expresan carácterísticas
especiales que agregan a los elementos conocidos y
comprometidos para un dominio especial. (entity,
boundary, etc.).
Valores etiquetados: permiten integrar
información que agrega inforemación al dominio en
que se está trabajando. Ej. Número de versiones y
el autor.
Restricciones: permiten agregar nuevas reglas y/o

modificar anteriores.
Mecanismos comunes
Divisiones Comunes:
Existe diferencias entre clase y objetos; la primera es
abstracta, mientras que los segundos son concretos. (dos
divisiones comunes), otro ejemplo es entre operación y
métodos etc.
Un segundo aspecto de divisiones comunes se da en la relación
entre interface y implementación;la interface declara un
contrato, y la implementación es una realización concreta de
ese contrato. Esta relación entre el contexto abstracto y la
implementación física del mismo se da cuando un componente
realiza a una interface.

Relaciones:
Se utilizan para escribir ¨modelos bien formados´ o sea
semánticamente consistente.
Definición: una relación es una conexión entre elementos.

d e p e n d e n cia
V e n ta n a
< < Interfac e> >
I Ayu d a abrir()
c errar() Eve n to
m over()
ay udaHelp()
dibujar() g e n e ra liz a ció n
m anejar()
re a liz a ci o n
a so cia ció n
V e n ta n a Co n so la Cu a d ro Dia lo g o Co n tro l
07/04/2005 Lic.
L a Daniel
s cu aRubén
tro Fernández
ti p o s dIriart
e re l a cio n e s 15
U M L , (U n ifie d M o d e lin g L a n g u a g e , L e n g u a je U n ific a d o d e M o d e la d o )
B lo q u e s b á s ic o s d e C o n s tr u c c ió n - R e la c io n e s
D e p e n d e n c ia A s o c ia c ió n G e n e r a liz a c ió n R e a liz a c ió n
A s o c ia c ió n A g r e g a c ió n C o m p o s ic ió n
1 3 /1 1 /2 0 0 3 L ic . D a n ie l R u b é n F e r n á n d e z I r ia r t 24
r .f .ir ia r t@ m e r c a d o to ta l.c o m
E le m e n to s E s tru ctu ra le s e le m e n to s d e
e le m e n to s d e a g r u p a m ie n to
c o m p o r ta m ie n to :
A s ie n t o
o rig e n : c h a r C adena R e q u e ri m i e n to s d e
tam año : c har
de responsabilidad D e te n id o V e n ta s
a s ig n a rs e () in te rfa ce
cla se co la b o ra ció n
A signar aula P a q u e te
e sta d o
C a so d e u so
S e rv id o r A s ie n t o
e le m e n to s d e n o ta c ió n
ru t in a . ja va o rig e n : c h a r e s s ó l o c o n c e p tu a l ,
tam año : c har d ib u ja r n o e xi s te e n e l
c a m p o fís i c o
a s ig n a rs e () M e n s a je
07/04/2005 nodo Lic. Daniel
cla se a ctivRubén
a Fernández Iriart 16
co m p o n e n te N o ta
13/11/2003 Lic. D aniel R ubén Fernández Iriart r.f.iriart@mercadototal.com
11 1 3 /1 1 /2 0 0 3 L ic. D an iel R u b én Fern án d ez Iriart 21
r.f.iriart@ m ercadototal.com r.f.iria rt@ m ercad o total.co m
Elementos Estructurales
A s iento
origen : c har Cadena
tam año : char de responsabilidad
asignars e() interface
colaboración
clase
Asignar aula
Caso de uso
Se rv ido r
A s iento
rutina.java origen : c har
tam año : char
asignarse()
nodo clase activa

componente
Los diagramas son vistas del modelo
Un modelo es una completa
descripción de un sistema
desde una perspectiva en State
State
State
particular State
Diagrams
Diagramas
Diagrams
Diagramas
Diagrams
Use Case Diagrams
de
Use
Use Case
Case
Diagramas deClases
Clases State
Use Case
Diagrams
Diagramas
Diagrams State
State
Use Case Diagrams
de Casos State
Diagrams
Use
Use
Use
Case
Case
Case de
Diagrams de Casosde
Diagrams de Diagrams
Diagrams
Diagramas
Diagramas
Diagrams
Diagramas
Diagrams de Uso
Uso Diagrams
Diagramas
Diagrams
Actividad de
deObjetos
Objetos
Actividad
Scenario
Scenario State
State
Scenario
Diagramas
Scenario
Diagrams
Diagramas State
State
Diagrams
Diagrams
Diagrams Diagramas
Diagrams
Diagramas
Diagrams
de
Diagrams
de Diagrams
Modelos de
deEstados
Estados
Secuencia
Secuencia
Scenario
Scenario
Component
Component
Scenario
Diagramas
Scenario
Diagrams
Diagramas
Component
Diagrams
Component de
Diagramas
Diagrams
Diagrams
Diagrams Diagramas
Diagramasdede Diagramas
Diagrams de
Diagrams
de
Diagrams
de Componentes
Despliegue
Despliegue Componentes
Colaboración
Colaboración
07/04/2005
48
Modelamiento Visual usando diagramas UML
Use-Case Diagram Class Diagram State Diagram add file
DocumentList
FileMgr Document
add( )
name : int
fetchDoc( ) delete( )
docid : int
sortByName( ) numField : int
Writing
add file [ numberOffile==MAX ] /
get( ) flag OFF
open( ) read() fill the
close( ) code..
FileList read( )
sortFileList( ) Openning
Use Case 1 add( )
fList create( )
fillDocument( )
delete( )
1 close file
Actor A Actor B
close file
Closing
Reading
rep
Use Case 2 File
<<entity>>
Repository
Customer
(from Persistence) GrpFile
read( )
name
name : char * = 0
read( )
readDoc( )
addr
open( )
readFile( )
create( )
fillFile( )
receive()
Use Case 3 withdraw()
Domain fetch()
send()
Deployment
Expert
UI
MFC Class Diagram

DocumentApp
ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼-¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö
DocumentList
RogueWave
Persistence
Repository Window95
Windows95
9: sortByName ( ) Windows95
global
¹®¼-°ü¸®
FileManager Å¬¶óÀÌ¾ðÆ®.EXE
¹®¼-°ü¸® ¾ÖÇÃ¸´
Definition mainWnd : MainWnd Windows
Package
NT
1: Doc view request ( ) L
Document
User Interface
Solaris
2: fetchDoc( )
¹®¼-°ü¸® ¿£Áø.EXE
4: create ( ) gFile : GrpFile
Diagram
Alpha
8: fillFile ( ) UNIX
ÀÀ¿ë¼-¹ö.EXE
Windows
NT
user : »ç¿ëÀÚ GraphicFile IBM
fileMgr : FileMgr Mainframe
3: create ( )
File FileList
6: fillDocument ( )
µ¥ÀÌÅ¸º£ÀÌ½º¼-¹ö
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
Component
Collaboration Diagram Forward Engineering (Code Generation)
Diagram
and
user
mainWnd fileMgr :
FileMgr
document :
Document
gFile repository Reverse Engineering
Edición código fuente, compilación, debug y link
Æ¯Á¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )
»ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
È-ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â 6: fillDocument ( )

¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼-
°´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.
7: readFile ( )
8: fillFile ( )
È-¸é °´Ã¼´Â ÀÐ¾îµéÀÎ 9: sortByName ( )

°´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡
º¸¿©ÁØ´Ù.
Sequence Diagram
Sistema Ejecutable
Diagrama de
Objetos
Comprador Confirmación de
Pedido
Gestor de Pedidos
Factura
Dominio
del modelo
de análisis
Solicitud de Pago
Entidad Solicitud de
Pago
Planificador de Pagos
Diagrama de Casos de Usos
Diagrama de Secuencia
C lie nte L ecto ra Pa nta lla te clad o Id en tific a ciò n d is p en s e r Tra ns a ccio ne s
c o m p ra rE n t ra d a s ve n d e d o r Introd u cir Tarje ta
c lie n t e -w e b c o m p r a rS u s c rip c ió n
Ta rje ta Introd u cida (ID )
< < in c lu d e > >
< < in c lu d e > > So l icita r PIN
Mos trar Peticiòn
Es p ecifica r PIN
Pa s a r PIN
c o b ra r
s e rvic io t a rje t a
Solicita r Va lid aciô n PIN
So licitar C a ntida d
Mos trar Peticiòn
e x a m in a rV e n t a s s u p e r vi s or In form ar C a ntida d
V is t a E x t ru c t u ra l
de Cas os de Us os Info rm a r C a n tid ad
Ve r Sa ldo
Solicita r C an tid a d (C )
Modela la funcionalidad del sistema
según los perciben los usuarios,
llamados actores.
22/11/2003 Lic. Daniel Rubén Fernández Iriart 68 24/11/2003 Lic. Daniel Rubén Fernández Iriart 83
r.f.iriart@mercadototal.com r.f.iriart@mercadototal.com
Un componente puede implementar varias clases,

Diagrama de Clases, y colaboraciones, y a su vez el mismo
(estructural y vista estática)
C lie n t e
componente realiza a una interface, y los
n o m b re : c h a r = i n i tv a l
t e l e fo n o : c h a r
componentes expresan
O p e r a c io n e s E n t id a d T a r j e t a s C r e d it o s
sus dependencias a través de las mismas
< >
A lta () y a t r ib u t o s C a rg o
No m b r e s
+ P r o p ie t a r io
1 d e p e n d e n c ia
interfaces
C om pon
d e R o le s
O b ra
< >

e n te 1
*
+ A d q u is ic ió n Ic lie n t e 1
Re s e rv a D e E n t ra d a s + o b ra
fe c h a : c h a r = c h a r
< < In t e r f ac e> >
Iv e n d e d o r
C om pon
< >
I s u p e r v is o re s e n te 2
G e n e r a liz a c ió n M u lt ip li I n te rf a c e 2
c id a d
S u s c r ip c ió n S e r ie X X X
s e rie : in t
R e s e r v a In d iv id u a l
Clase2 Clase1
0 ..*
0 .. *
+ r e p r e s e n ta c io n e s
Diagrama de
07/04/2005 Lic. Daniel Rubén Fernández Iriart Colaboración1 21
1 ..*
* 1
Componentes
E n t ra d a
R e p r e s e n t a c ió n
13/11/2003 v e n d e r(c :c lie n t e )()

in t e rc a m b ia r()
* Lic. Daniel Rubén Fernández Iriart
1
52 13/11/2003 Lic. Daniel Rubén Fernández Iriart 55
Diagrama de Estados con Subestados
Diagrama de Actividad
<<t a nq ue >>
Seleccionar obra
Vacio
<<t a nq ue >>
empieza
Lleno Poco
Vacío
Programar obra
Medio
Vacío
Muy
detecta( a ) Vacío Anunciar obra Comprar guiones
y música Contratar artistasObra
Comprar equiposHacer vestuario
tanque Lleno( Abre la Valvula ) detecta( b )
Detector y Emisor
de Eventos
tanque lleno( cierra canilla )

tanque vacio( abre canilla )
Vender entradas
<<C a nilla >>
< <C an illa >> ensayar
Abierta
Cerrada
Valvula Valvula Vista dinámica de

Cerrada Abierta Ensayo general
Interacción: diagrama
de Actividades
Tanque Vacio( Cierra la Valvula )
13/11/2003 Lic. Daniel Rubén Fernández Iriart 77 13/11/2003 Lic. Daniel Rubén Fernández Iriart 80
r.f.iriart@mercadototal.com Representar r.f.iriart@mercadototal.com
Diagrama de despliegue
E nt id a d T a r je t a V is t a E s t á t ic a F í s ic a d e
C r é d it o D e s p lie g u e
c o m p ra rE n t ra d a s ve n d e d o r
D is p o s it iv o S e r v id o r D e E n t r a d a s c lie n t e -w e b c o m p r a rS u s c rip c ió n
< < in c lu d e > >

< < in c lu d e > >
P ro c e s o
C a r g o s T a r je t a s
P ro c e s o d e c o b ra r
B d a to s E n tra d a s
V e n d e d o rE n tra d a s
e x a m in a rV e n t a s s u p e r vi s or
de Cas os de Us os
D is p o s it iv o
C lie n t e
in t e r f a c e
d e c lie n t e C lie n t e W e b
07/04/2005 Lic. Daniel Rubén Fernández Iriart
según los perciben los usuarios, 22
llamados actores.
13/11/2003 Lic. Daniel Rubén Fernández Iriart r.f.iriart@mercadototal.com
62 16/11/2003 Lic. Daniel Rubén Fernández Iriart 68
y colaboraciones, y a su vez el mismo
interfaces
C om pon
e n te 1
C om pon
e n te 2
I n te rf a c e 2
Clase2 Clase1
Colaboración1 Diagrama de
Componentes
07/04/2005
13/11/2003 Lic. Daniel
Lic. Daniel Rubén
Rubén Fernández
FernándezIriart
Iriart 23
55
Diagramas de UML y el
Proceso Unificado de
desarrollo de Software

descripción de un sistema
desde una perspectiva en State
State
State
particular State
Diagrams
Diagramas
Diagrams
Diagramas
Diagrams
Use Case Diagrams
de
Use
Use Case
Case
Diagramas deClases
Clases State
Use Case
Diagrams
Diagramas
Diagrams State
State
Use Case Diagrams
de State
Diagrams
Use
Use Case
UseCase
Case de
Diagrams de Casosde
Casos
Diagrams
Diagramas
Diagramas
Diagrams
Diagramas
Diagrams de Uso Diagrams
Diagramas
Diagrams Uso de
Actividad
Actividad deObjetos
Objetos
Scenario
Scenario State
State
Scenario
Diagramas
Scenario
Diagrams
Diagramas State
State
Diagrams
Diagrams
Diagrams Diagramas
Diagrams
Diagramas
Diagrams
de
Diagrams
de Diagrams
Modelos de
deEstados
Estados
Secuencia
Secuencia
Scenario
Scenario
Component
Component
Scenario
Diagramas
Scenario
Diagrams
Diagramas
Component
Diagrams
Component de
Diagramas
Diagrams
Diagrams
Diagrams Diagramas
Diagramasdede Diagramas
Diagrams de
Diagrams
de
Diagrams
de Componentes
Despliegue
Despliegue Componentes
Colaboración
Colaboración


Bloques básicos de
Construcción

Bloques básicos de Construcción
Elementos Relaciones Diagramas

Bloques básicos de Construcción-
Elementos

Bloques básicos de Construcción- Elementos
Estructurales Comportamiento Agrupación Anotación

Elementos Estructurales
Asiento
origen : c har Cadena
tam año : c har
de responsabilidad
asignars e() interface
clase colaboración
Asignar aula
Caso de uso
Se rv ido r A s iento
rutina.java origen : c har
tam año : char
asignarse()
nodo clase activa

componente
Bloques básicos de Construcción—
Elementos Estructurales:
Son las partes estáticas de un modelo, representan cosas
que son conceptuales o materiales, son siete.

Clase
Definición: una clase es una descripción de un conjunto
de objetos que comparten los mismos atributos,
operaciones, relaciones y semántica. Una clase
implementa una o más interfaces
A siento
origen : char
tam año : char
asignarse()

Interface
Definición: es una colección de operaciones que especifican
todos\parte\o un servicio de una clase o componente.
Define un conjunto de especificaciones de operaciones,
describe el comportamiento visible externo de los elementos
que la realizan, sea una o varias clases o componentes. No
describe jamás la implementación de la operación.
Una interface raramente se encuentra aislada, siempre se
encuentra haciendo visibles comportamientos de clases y-o
componentes

Colaboraciones
Define una interacción, integrada por elementos
que en forma conjunta proporcionan un
comportamiento cooperativo que es mayor a la
suma de todos los comportamientos de los
elementos involucrados.
Cadena
de reponsabilidad

Casos de Uso
es una colección de operaciones que especifican
todos\parte\o un servicio de una colaboración.
Es una descripción de un conjunto de acciones que se realizan
ante una posible precondición, paso a paso y que describen
una colaboración, (por esta razón, un caso de uso es realizado
por la colaboración), observable y con un objetivo visible por
parte de un usuario. Es una serie de requerimientos de
usuario
Asignar aula

Clases activas
Es una clase cuyos objetos tienen uno
o más procesos o hilos de ejecución y
que por lo tanto pueden dar origen a
actividades de control. Se grafica de
la misma manera que una clase pero
con líneas más gruesas
A siento
origen : char
tam año : char
asignarse()

Componentes
Un componente es la representación
física de un elemento de
representación lógica, (ej. Interfaces,
Clases y Colaboraciones,). Es una
parte física y reemplazable de un
sistema y que proporciona la
implementación de una o varias
interfaces.
rutina.java

Nodo
Es un elemento físico, que existe en
tiempo de ejecución y representa un
recurso computacional, puede tener
memoria y capacidad de
procesamiento. En él pueden residir
varios componentes.
Se rv ido r

Bloques básicos de
Construcción-
elementos de
comportamiento:
Son las partes dinámicas de los
modelos UML; representan un
comportamiento en el tiempo y el
espacio.

elementos de
elementos de agrupamiento
comportamiento:
R equeri m i entos de
Ventas
Detenido
Paquete
estado
elementos de notación
es s ólo conceptual,
dibujar no exis te en el
cam po fís ico
Mensaje
Nota
Estados
Es el estado que puede tener un
determinado objeto en el tiempo y el
espacio. El conjunto de estados que
un objeto puede tener y su orden
secuencial de aparición se expresa
mediante una máquina de estado. Por
esta razón un determinado estado es
parte de una comportamiento que un
objeto puede tener.
Detenido

Bloques básicos de Construcción-
elementos de agrupación:
Son partes organizativas de UML.
Paquete
Es un mecanismo de
propósito general para
organizar elementos dentro
de ellos. No existen en la
realidad, son meramente
conceptuales
R equeri m i entos de
Ventas

UML, (Unified Modeling Language, Lenguaje Unificado de Modelado)
Bloques básicos de Construcción- Relaciones
Dependencia Asociación Generalización Realización
Asociación Agregación Composición

Bloques básicos de
Construcción-
elementos de anotación
Son las partes explicativas del UML,
clarifican, explican, exhiben
restricciones, aclaraciones etc.
es s ólo conceptual,
no exis te en el
cam po fís ico

Bloques
Básicos de
Construcción
-Relaciones:

Bloques Básicos de Construcción-
Relaciones:
Se utilizan para escribir ¨modelos bien formados´ o sea
semánticamente consistente.
Definición: una relación es una conexión entre elementos.
d e p e n d e n c ia
V e n ta n a
< < In t e r fa c e > >
IAyuda a b rir()
c e rra r() E v e n to
m o ve r ( )
a y u d a H e lp ()
d ib u ja r() g e n e ra liz a c ió n
m a n e ja r()
re a liz a ci o n
a so c ia c ió n
V e n ta n a C o n so l a C u a d ro D ia lo g o C o n tr o l
L a s c u a t ro ti p o s d e re l a c io n e s
Compatibilidad entre
Jerarquía y Relación
Herencia Generalización
Colaboración Dependencia
Asociación
Asociación Agregación
Composición

Relación
Dependencia

Dependencia
•La dependencia es una relación de üso¨ (un elemento utiliza a
otro), es por esta razón que el estereotipo más común con que se
manifiesta la relación es üse¨.
•Es una relación semántica entre dos elementos, en la cual un
cambio a un elemento, (elemento independiente, también llamado
destino), puede afectar a la semántica del otro elemento,
(elemento dependiente, también llamado origen), pero no
necesariamente a la inversa.
Reprensentación gráfica
fram ew ork R ec epc iòn de pedidos

MensajeUsuario
M ec anis m o F ac turac iòn valor : char = initval
M ec anis m o C om probac iòn formulario
analizar() dato : string = initval
cuenta : int = initval
P antalla

Dependencia
(Estereotipos)
Si se quieren especificar ciertos matices en la relación entre

elementos, UML define 17 diferentes esteriotipos para la
relación Dependencia. Los mismos pueden clasificarse según
el siguiente esquema:
A) Para la conexión D) Cuando se modela
entre elementos en interacciones entre objetos
diagramas de clase.
B) Para
dependencias E) Para dependencias entre
entre Paquetes máquinas de estado
F) Cuando se organizan
C) Para dependencias
elementos dentro de un
entre Casos de Uso
subsistema o modelos
Dependencia
A) Para la conexión entre elementos en diagramas de clase.
1. Derive: Especifica que el origen puede calcularse a partir del destino.

2. Friend: Especifica que el origen tiene una visibilidad especial en el destino,
(clases amigas de C++).
3. Instanceof: Especifica que el objeto origen es una instancia del clasificador

destino.
4. Instantiate: Especifica que el origen crea instancias del destino.

5. Powertype: Especifica que el destino es un supratipo del origen; un supratipo
es un clasificador cuyos objetos son todos los hijos de un padre dado.
6. Bind: Especifica que el origen de la Dependencia instancia a la plantilla destino
con los parámetros reales dados.
7. Refine: Especifica que el origen está a un grado de abstracción más detallado

que el destino.
8. Use: Especifica que la semántica del elemento origen depende de la semántica

de la parte pública del elemento destino.

Dependencia
B) Para dependencias entre Paquetes, (se aplican dos

estereotipos).
1. Access: Especifica que el paquete origen tiene permisos para

referenciar elementos del paquete destino.
2. Import: Un tipo de acceso que especifica que los contenidos
públicos del paquete destino entran en el espacio de nombres del
origen, como si hubiesen sido declarados en el origen.
C) Para dependencias entre Casos de Uso, (se aplican

dos estereotipos)
1. Extend: Especifica que el caso de uso destino extiende el
conportamiento del origen.
2. Include: Especifica que el caso de uso origen incorpora explícitamente
el comportamiento de otro caso de uso en la posición especificada por el
destino.

Dependencia
D) Cuando se modela interacciones entre objetos, (se
aplican tres estereotipos).
1. Become: Especifica que el destino es el mismo objeto que el origen,

pero en un instante posterior y posiblemente con diferentes valores,
estados o roles.
2. Call: Especifica que la operación origen invoca a la operación destino.
3. Copy: Especifica que el objeto destino es una copia exacta , pero
independiente del origen.
E) Para dependencias entre máquinas de estado, (se
aplica un estereotipo).
1. Send: especifica que la operación origen envía el evento a un
objeto destino.
F) Cuando se organizan elementos dentro de un

subsistema o modelos, (se aplica un estereotipo)
1. Trace: especifica que destino es un antecesor histórico del
origen.
Relación
Generalización

Generalización
Definición: Una generalización es una relación entre un elemento
más general, (E másG), y otro más específico, (E más E); siempre
con elementos del mismo tipo.
Clas e m ás G
C asoU so m ás G
(fro m Use Ca se V i e w)
Clas e m ás E
• La Generalización es o se llama relación Ës-del-tipo-de¨.

Cas oUs o m ás E
• El elemento más significativo se llama ¨superclase, supertipo,
(fro m Use Ca se V i e w)
padre, antecesor¨.
•El elemento menos significativo se llama ¨subclase, subtipo, hijo,
descendiente¨.

Generalización
• En la Generalización los objetos hijos, (instancias), se pueden
emplear en cualquier lugar que pueda aparecer el padre, pero no a la
inversa.
• lo anterior marca el ¨Principio de Sustitución¨, el hijo puede
sustituir al padre.
•El hijo puede agregar nueva estructura y comportamiento a la
relación
• Su representación gráfica es una línea continua o flecha con punta
vacía y grande, apuntando al elemento más general.
• El hijo hereda las propiedades del padre, (ej. Atributos y
operaciones), además de contener las propias.
• El hijo puede tener ninguno, uno o varios padres.
• Cuando el hijo tiene más de un padre se habla de herencia múltiple.
• Cuando un hijo no tiene padre se habla de elemento raíz o base.
•Entre una Ïnterfaceÿ una ¨clase¨ o ¨componente¨ se describe
una generalización.

Generalización
Restricciones aplicadas a la Generalización
1. Complete: Especifica que todos los hijos en la Generalización se han

especificado en el modelo, (aunque puede que algunos se omitan en el
diagrama), y no se permiten hijos adicionales.
2. Incomplete: Especifica que todos los hijos en la Generalización se han

especificado en el modelo, (aunque puede que algunos se omitan en el
diagrama), y que se permiten hijos adicionales.

Relación
Asociación

Asociación
Definición: Una asociación es una relación estructural que especifica
que los objetos de un elemento se encuentran conectados con los
objetos de otro, Elem1 Elemn o un mismo elemento Elem5
y su representación gráfica en una línea continua
La navegabilidad entre los objetos, salvo que se indique, siempre
supone en ambos sentidos, y su representación gráfica es:
• Existen cuatro Adornos que se aplican a la asociación y son :
• nombre, rol, multiplicidad, agregación
nom bre role s
+ contra ta da + contra ta nte

Trabaja para
pe rsona
e m pre sa + todo
1..* * 1
a gre ga ción
M ultiplicida d
Asocia ción
1..*
De pa rta m e nto
+ P a rte
Asociación
Navegación: la navegación en una asociación siempre es bidireccional, salvo que
se especifique lo contrario y entonces deberá especificarse el sentido de la
navegación. Quiere decir que desde un objeto se puede llegar facílmente y directamente a
otro objeto, normalmente debido a que el objeto origen almacena referencias del objeto
destino
navegación de la Quiere decir que desde el usuario se
asosiación puede conocer cuál es su clave, el
camino inverso no está permitido
+roll: propietario
Usuario
clave
Visibilidad: La posible amplitud de navegación de la

navegación será determinada por las asociación
características de visibilidad que le
querramos dar a la asociación; en nuestro +roll: propietario
caso queremos limitar la visibilidad con respecto GruposUsuario Usuario
clave
al acceso de las claves, ya que sólo un usuario *
+GrupoUsuario * 1 * -clave
con el roll de propietario tiene derecho a
observar o ver los objetos de la instancia de
clave. En el ejemplo vemos que los usuarios
pueden navegar a los grupos de usuarios y visibilidad de
visiversa, pero no así con clave la asociacion

Asociación
Roll: representa el comportamiento que un elemento lleva a cabo en el contexto
que participa. Este comportamiento dentro del contexto de una relación, siempre
es estático. Todo rol tiene un nombre y generalmente se lo aplica cerca del
elemento que representa.
Agregacion: Es una forma de asociación en donde se especifica una relación

todo-parte entre un agregado, (el todo), y las partes que lo componen. Está
representado por un rombo o diamante hueco, (no lleno) en el extremo de la
asociación donde se conecta el elemento agregado. Una forma más ¨fuerte¨ de
agregación es la conocida como
Composición o Agregación Compuesta, esta se representa también con

un rombo pero éste no es ¨hueco¨ es ¨lleno¨. Existen dos restricciones para la
¨composición¨: 1) ¨cuando muere el todo muere la parte¨ y 2) ¨la parte sólo es
accedida únicamente a través del todo¨.
F a c u lta d D e p a r ta m e n to s
E d ific io
A lu m n o P r o fe s o r
A u la s

Asociación
•Restricciones: Si se desea aplicar matices dentro los
conceptos aplicados hasta ahora, con respecto a las
asociaciones podemos expresar las siguientes restricciones:
•Implicit: especifica que la relación no es explícita, sino más bien,

es sólo conceptual.
• Ordered: especifica que el conjunto de objetos en un extremo de

una asociación sigue un orden explícito.
• Changeable: Se pueden añadir, eliminar y modificar libremente los

enlaces entre objetos.
• addOnly: se pueden añadir nuevos enlaces desde un objeto del

otro extremo de la asociación.
•Frozen: un enlace, una vez añadido desde un objeto del otro

extremo de la asociación, no se puede modificar ni eliminar.

Relación
Realización

Realización
Realización: Es una relación semántica entre clasificadores, en la cual un
clasificador especifica un contrato que otro clasificador garantiza que cumplirá. La
representación gráfica es una línea discontínua con una punta de flecha hueca , (vacía) y
grande, que apunta al clasificador que especifica el contrato. Es utilizada bajo dos
circunstancias:
1) bajo el contexto de las interfaces: la interface especifica lo que la clase o componente
ejecuta; una clase-componente puede realizar a una-varias interfaces y una interface
puede ser realizada por varias clases-componentes.
La interface esuna Colección implementaci mplenta

de operaciones, especifica los regla onDeClaseA claseA
Clase o
contratosque se llevan a cabo Pedido.dll
componente
por la clase-componente
AgenteDe
ReglasNegocioPedido
Reglas
añadirRegla()
cambiarRegla() realizacióndeuna
<<Interface>>
explicarAcción() Interfaceporun hacedetoto
AgenteDeReglas
componente
Realización de
añadirRegla()
una interface
cambiarRegla()
por una clase
explicarAcción()

Realización
2) bajo el contexto de las colaboraciones: en este caso se usa la relización para
especificar la relación entre un caso de uso y la colaboración que realiza ese caso de
uso
Validación
Re a liza ción
<<Caso de Uso>>
Validar Usario
Bloques Básicos de
Construcción-
Diagramas:

descripción de un sistema desde
una perspectiva en particular State
State
State
State
Diagrams
Diagramas
Diagrams
Diagramas
Diagrams
Diagrams
Use
UseCase
Case de
deClases
Clases
Use
Use Case
Diagramas
Case
Diagrams
Diagramas State
State
Use Case Diagrams
Diagrams
de State
State
Diagrams
Use
Use
Use
Case
Case
Case de
Diagrams deCasos
Casosde
Diagrams
Diagramas
Diagramas
Diagrams
Diagramas
Diagrams de Uso Diagrams
Diagramas
Diagrams Uso de
Actividad
Actividad deObjetos
Objetos
Scenario
Scenario State
State
Scenario
Diagramas
Scenario
Diagrams
Diagramas State
State
Diagrams
Diagrams
Diagrams Diagramas
Diagrams
Diagramas
Diagrams
de
Diagrams
de Diagrams
Modelos de
deEstados
Estados
Secuencia
Secuencia
Scenario
Scenario
Component
Component
Scenario
Diagramas
Scenario
Diagrams
Diagramas
Component
Diagrams
Component de
Diagramas
Diagrams
Diagrams
Diagrams Diagramas
Diagramasde
de Diagramas
Diagrams de
Diagrams
de
Diagrams
de Componentes
Implantación
Implantación Componentes
Colaboración
Colaboración

Bloques básicos de Construcción- Diagramas
Clases y Componentes
Vista Estática Objetos
Lógica
Despliegue
Vista Estática
Extructural Física de
Despliegue
Casos de Uso
Vista de Casos de
Uso
Secuencia y
Vista de
Interacción Colaboración
Dinámica
Estados
Actividad
Diagrama
Estructurales

Vista estática lógica
Diagrama de clases y componentes
Modelan la vista estática de un sistema. Expresan las colaboraciones
entre las clases de un dominio, los roles que cada una de ellas juegan
en la relación entre clases, las relaciones de multiplicidad, pudiendo
mostrar atributos, estereotipos y operaciones, realización de
interfaces. También expresan la visibilidad de un atributo y-o
operación, (privado, público, protegido).
Expresan los esquemas de jerarquía entre distintas abstracciones de

clases o conjuntos de ellas, mediante las distintas posibles relaciones
entre los elementos factibles de modelar, (asociaciones,
dependencias, generalizaciones y realizaciones), muestran como
estos subconjuntos son factibles de empaquetarse en distintos
subsistemas. A través del mismo es factible la ingeniería directa y
inversa
Definición: muestra un conjunto de interfaces,
colaboraciones y sus relaciones.
Diagrama de Clases,
(estructural y vista estática)
C lie n t e
n o m b re : c h a r = i n i tv a l
t e l e fo n o : c h a r
O p e r a c io n e s E n t id a d T a r j e t a s C r e d it o s < >
A lt a () y a t r ib u t o s C a rg o
+ P r o p ie t a r io
No m b r e s 1 d e p e n d e n c ia
d e R o le s
O b ra
< >

*
+ A d q u is ic ió n Ic lie n t e 1
Re s e rv a D e E n t ra d a s + o b ra
fe c h a : c h a r = c h a r
< < In t e r f ac e> >
Iv e n d e d o r
< >
I s u p e r v is o re s
G e n e r a liz a c ió n M u lt ip li
c id a d
S u s c r ip c ió n S e r ie X X X R e s e r v a In d iv id u a l
s e rie : in t
0 ..*
0 .. *
+ r e p r e s e n ta c io n e s
1 ..*
* 1
E n t ra d a
R e p r e s e n t a c ió n
1
07/04/2005 v e n d e r(c :c lie n t e )()
in t e rc a m b ia r()
* Lic. Daniel Rubén Fernández Iriart 70
Diagrama de Clases, Paquetes o Subsistemas
¨Hola, Mundo¨
H o la M u n d o
ja va
a p p le t
p a i n t ()
A p p le t
g . d ra w S t ri n g
(¨H o l a , M u n d o ! ¨)
awt
G ra p h i c s
Panel
d ra w S t ri n g ( )
C o n ta i n e r
l a ng
< 
Im a g e
O b je ct
( fr o m l a n g )
Com ponet

Componentes
Los componentes pertenecen al mundo de los bits, por

tanto estamos hablando de software, de una
representación de elementos físicos que se pueden
localizar en un nodo, tales como archivos, bases de
datos, librerías , documentos, todo tipo de ejecutables, y
normalmente representan el empaquetamientos físico
de clases, interfaces y colaboraciones, las cuales
expresan una representación lógica de la realidad que
queremos representar. Por lo tanto una diferencia entre
clase y componente, es que este puede residir en un
nodo y la clase no.
rutina.java
Definición: es una parte física y reemplazable de un

sistema con un conjunto de interfaces y proporciona la
07/04/2005 realización de esas
Lic. Daniel interfaces.
Rubén Fernández Iriart 72
y colaboraciones, y a su vez el mismo
interfaces
C om pon
e n te 1
C om pon
e n te 2
I n te rf a c e 2
Clase2 Clase1
Colaboración1
Estereotipos de componentes.
1. Executables: especifica un componente

que se puede ejecutar en un nodo.
2. Library: especifica un componente que es
una biblioteca de objetos estática o
dinámica.
3. Table: especifica un componente que
representa una tablas de una base de datos.
4. File: especifica un componente que
representa un documento que contiene
código fuente o datos.
5. Document: especifica un componente que
representa un documento.

Sugerencias y consejos.
Tenga en cuenta que un componente bien estructurado...
• proporciona una abstracción de algo extraído de la parte física del

sistema.
•Proporciona la realización de un pequeño conjunto bien definido de
interfaces.
•Implementa directamente un conjunto de clases que colaboran
entre sí para llevar a cabo la semántica de esas interfaces con
economía y elegancia.
•Está debílmente acoplado en relación con otros componentes; lo
más frecuente es modelar componentes a través de relaciones de
dependencia y de realización solamente.
Cuando dibuje un componente en UML....

• use la forma iconica de una interface, salvo que desee mostrar las
operaciones.
•Sólo muestre las interfaces necesarias para lograr mayor
compresión, de ese componente en el contexto dado.

Diagrama de Componentes,
(estructural y vista de implementación)
Una interface puede ser realizada por más de un componente;

un componente puede llamae a otro componente a travéz de su
Interface o directamente a él.
ProcesaCargo
T arjetaCredito BasesDe
DatosEntradas
Cargo
vendedor
DeEntradas
Icliente
Ivendedor Isupervi
sores
Iventa
Suscripcion

IVenta
Individuales
Diagrama de Componentes
Entidad de T arje ta s
<<Ap plication>> de Cre d ito
CargosD e Tarje
tasD e Cre dito
Cargo
E stado
CompraBD Entradas
<<App licatio n>>

<<App lication>>
Ve nde dor de
Inte rface De
Entradas G e stor
Ve ntas de
Grupo
Ve ntas
Ve ntas de Individuale s
Suscripción <<Ap plication >>
Inte rface de
Ve nde dor
Supe rvisor
<<Applicatio n>>
Inte rface de
Clie nte
Clie nte
Ve nde dor

Diagrama
Estructurales –
Vista estática física

Un diagrama de despliegue muestra la
disposición física de los recursos de ejecución
computacional, tales como computadores y sus
interconexiones. Cada recurso computacional
es llamado Nodo. En un diagrama de despliegue
pueden existir varios Nodos, y los mismos se
encuentran interrelacionados por conexiones.
Cada nodo tiene por lo menos memoria y a
menudo también capacidad de proceso, y todo
tipo de dispositivos que se necesiten expresar,
y la la conexión entre ellos y la ubicación de sus
procesos, expresados generalmente por
componentes, en los computadores.
Cada procesador o dispositivo o conexión puede
ser especificada y alguna información
expresada en los iconos de los mismos y por
supuesto cambiar sus propiedades a través de
editar las especificaciones

Diagrama de despliegue
E nt id a d T ar je t a V is t a E s t á t ic a F í s ic a d e
C r é d it o D e s p lie g u e
D is p o s it iv o S e r v id o r D e E n t r a d a s
P ro c e s o
C a r g o s T a r je t a s
P ro c e s o d e
B d a to s E n tra d a s
V e n d e d o rE n tra d a s
D is p o s it iv o
C lie n t e
in t e r f a c e
d e c lie n t e C lie n t e W e b

Diagrama Estructurales –
Vista de Casos de Uso
Los diagramas de Caso de Uso, captura el
comportamiento de un sistema, subsistema, una
clase, tal como se muestra a un usuario esterior.
Describe una interacción entre el sistema y los
actores.
Los actores son usuarios u otros sistemas y
muestra un conjunto de Casos de Uso y actores y
sus relaciones. Estos diagramas son una unidad
coherente de funcionalidad sin revelar la
estructura y el funcionamiento interno.

Tipos de relaciones de Casos de Uso
Relación Función Notación

Asociación La línea de comunicación entre un actor y un caso
de uso en el que participa
Dependencia La inserción de comportamiento adicional en un extend

caso de uso base que no tiene conocimiento sobre
él
Generalización Una relación entre un caso de uso general y un

caso de uso particular, que hereda y añade
propiedades a aquél
Realización Una colaboración realiza a un caso de uso
Dependencia Inserción de comportamiento adicional en un caso Include

de uso base, que describe explícitamente la
inclusión
Por qué Casos de Uso ???
.
•Proporcionan un medio sistemático e intuitivo de

capturar requisitos funcionales
• Dirigen todo el proceso de desarrollo bajo el
esquema de que tanto el: análisis, como el diseño, y
prueba se infieren de los casos de uso.

• Para Capturar Requisitos funcionales......
• Es necesario un adecuado vehículo de comunicación en
donde se formalicen las especificaciones de
requerimientos de un sistemas.
• Ese vehículo donde ser comprendido de manera
universal por todos los usuarios.
• El mismo debe ser intuitivo, a fin de facilitar la
comprensión.
• Deben poder expresarse en el mismo todas las
funciones y sus actores.
• El cúmulo de los mismos deben representar el sistema
todo.
• El mismo debe funcionar como un ïnstrumento de
acuerdo¨, acuerdos básicos y tácitos, de entendimiento
entre los distintos usuarios. Esto no se lograría si no se
cumplimentaran los puntos anteriormente expresados.

• Para Dirigir el Proceso......
• Los distintos ¨flujos de trabajo¨ son consecuencia y van realizando a
los Casos de Usos. Los desarrolladores ubicarán las distintas clases del
sistema, que los implementadores implementarán, para luego ser
testeadas si cumplen con los requerimientos expresados en los Casos de
Usos.
Requisitos Análisis Diseño Implementación Prueba
Los casos de usos se representan en la elipse sombreada entrelazando los diferentes flujos de
trabajo.
Tiene Tiene Tiene Tiene

relaciones de relaciones de relaciones de relaciones de
traza con traza con traza con traza con
Modelo de Casos
de Uso Modelo de Análisis Modelo de Diseño Modelo de Implem. Modelo de Prueba
c o m p ra rE n t ra d a s ve n d e d o r
c lie n t e -w e b c o m p r a rS u s c rip c ió n
< < in c lu d e > >

< < in c lu d e > >
c o b ra r
e x a m in a rV e n t a s s u p e r vi s or
de Cas os de Us os

según los perciben los usuarios,
llamados actores.
Use
Acordar Cré dito
U suario H ace r Pe dido <<includ e >>
<<inclu de >> <<e xte nd >>

<<includ e > > Solicitar catálogo
Suministro de datos de clie nte s Pe dir Producto
Pagar
Pagar Al contado Pagar a Cré dito

Vistas de Interacción
Vistas de la Máquina de Estado
Términos y Conceptos:
•La máquina de estados describe el comportamiento dinámico de los
objetos, en un cierto plazo, modelando los ciclos de vida de los
objetos de cada clase. Cada objeto es una entidad aislada que se
comunica con el resto del mundo detectando eventos y respondiendo
a ellos.
•2 o más objetos con el mismo estado, reaccionan realizando

acciones iguales a eventos iguales.
•2 o más objetos con diferentes estados, pueden reaccionar

realizando acciones diferentes al mismo evento.
•Las máquinas de estado describen comportamiento dinámico de

clases, casos de usos, colaboraciones y métodos.

Cuando se produce el evento ¨Detección de Intruso¨, el
sistema dispara una transición ; como parte de la transición, se
lleva a cabo la acción ¨Llamar a la Policía¨, que es una
acción, pues es algo atómico, ( y normalmente rápido); al llegar
al estado ¨Sonando¨, luego de ejecutarse la acción que lo
cambió de estado, en el estado ¨Sonando¨comienza la
actividad, que se mantiene en el tiempo, y hasta que el evento
reiniciar, dispare una nueva transición, interrumpa la actividad
Sonando, y cambie el estado a Vigilando
detección de un intruso / llamar a la policía Sonando hacer

Vigilando
actividad sonar alarma
reiniciar

Diagramas de Estado
Modelan los aspectos dinámicos de los sistemas.

Generalmente esto supone el modelaje de los
objetos reactivos. Un objeto reactivo es aquél que
reacciona generando un comportamiento de cambio
de estado, ante eventos que lo impactan desde el
mundo exterior.
Un diagrama de estados muestra una máquina de

estados.

Máquina de estado: es un gráfico de estados y de
transiciones. Se une a una clase y describe,
generalmente, la respuesta de una instancia de la clase,
a los eventos que recibe. También se pueden unir a las
operaciones, a las colaboraciones y a los casos de uso.
•Cuando un objeto detecta un evento, responde de

una manera según sea su estado actual. Su respuesta
puede incluir la ejecución de una acción y un cambio
a un nuevo estado
Estado: es una condición o situación en la vida de un

objeto de una clase dada, durante la cual satisface una
situación, realiza alguna actividad o espera algún
evento.
Subestado: es un estado anidado dentro de otro.
Evento: es la especificación de un acontecimiento
significativo que ocupa un lugar en el tiempo y en el
espacio. Puede disparar una transición de estados.
Cualquier cosa que puede afectar al estado de un objeto,
puede ser considerado evento. No es algo continuo, es
simultáneo. Un objeto maneja un evento a la vez.
Guarda: son las condiciones que se deben cumplir para
que sucedido el evento, el objeto inicie una transición
hacia un nuevo estado
Transición: es una relación entre dos estados, que
estando en un estado paso a otro estado, cuando ocurra
un evento determinado y se satisfagan unas condiciones
especificadas.
Acción: es una computación atómica ejecutable que
produce un cambio en el estado del modelo.
Actividad : ejecución no atómica en curso dentro de una
máquina
07/04/2005
de estados;Lic.
tiene una duración y posibles 92
Daniel Rubén Fernández Iriart
puntos de interrupción. r.f.iriart@mercadototal.com
Tanque de Agua
El ejercicio de tanque de agua nos permite
visualizar cómo
un Objeto al cambiar de estado, puede
impactar a uno o más
Objetos, y como consecuencia de este
impacto, también estos últimos modifican
sus estados.
Cuando se tienen dos o más objetos que

puedan impactarse
entre sí, es bueno estudiar si podemos
resumir el caso a que,
se parta siempre de uno sólo de ellos
hacia los demás.

El caso del tanque de agua, presenta estas alternativas, y
puede resumirse a que:
el tanque se encuentra vacío, y por supuesto para que se
halla vaciado, tiene que tener la válvula abierta y la canilla
cerrada;
y para poder llenarse, debe primero cerrarse la válvula y
abrirse la canilla, además debe haber un sensor para
determinar que el tanque ya está lleno o vacío, y
disparar los adecuados eventos
a) Tanque vacío ---Æ cerrar válvula y abrir canilla.
b) Tanque lleno ---Æ abrir válvula y cerrar canilla

Diagrama de Estados con Subestados
<<t a nq ue >>
Vacio
<<t a nq ue >>
Lleno Poco
empieza
Vacío
Medio
Vacío
Muy
detecta( a ) Vacío
Send
tanque Lleno( Abre la Valvula ) detecta( b )

Detector y Emisor
de Eventos
tanque lleno( cierra canilla )

Send
tanque vacio( abre canilla ) Send
Send < <C an illa >>

<<C a nilla >>
Abierta
Cerrada
Valvula Valvula
Cerrada Abierta
07/04/2005
Tanque Vacio( Cierra la Valvula ) Lic. Daniel Rubén Fernández Iriart 95
Diagrama de Actividad y de Estados con Subestados
Comienzo
Alarma en
espera
examinar Sensor/Actuador de
Reloj horario y tiempo Tiene baterias
f uertes?
se cambia Tiempo de sonar acab...

f echa? si tiene
No tiene baterias f uer...
Ala rma
No cam.. . sonando
Cambiar Bateria Puesta
Fuerte Dèbil
f echa
No cam...
cam biar
hor a? No cam .. .
No cam... Led
Cambiar Prendido Bateria debiles y / o sacar bate..
Bateria No
Hora puesta
Cambiar
minutos?
Led
Apagado
Cambiar
minutos Fin
Diagrama de activ idad para el f lujo de datos Examinar Reloj y màquinas de estado para las clases Baterìa,
Led, Alarma y Sensor/Actuador de f echa, horario y Tiempo programado de alarma sonando

Un Caso especial de diagrama de estados, es

un diagrama de actividad, en donde todas o
la mayoría de las transiciones se disparan
por la terminación de las actividades en el
estado origen; muestra el flujo de control
entre actividades...mientras que el
diagrama de estados expresa el flujo de
control entre estados. Este tipo de
diagrama es el homólogo al Diagrama de
Flujos de Datos, en una metodología de
análisis y diseño estructurado. En el tiene
un icono especial, que es una línea ya sea
horizontal o vertical y que es llamada
sincronización, y sirve para establecer la
frontera donde confluyen varias actividades
paralelas. Este tipo de diagrama es especial
para expresar comportamiento de métodos,
colaboraciones, etc.

Seleccionar obra
Programar obra
Anunciar obra Comprar guiones

y música Contratar artistasObra
Comprar equiposHacer vestuario
Vender entradas
ensayar
Vista dinámica de
Ensayo general
Interacción: diagrama
de Actividades

Representar r.f.iriart@mercadototal.com
Diagramas de interacción, de secuencia
y de colaboración.
Un diagrama de interacción muestra la interacción de mensajes
entre diferentes objetos de un escenario o colaboración. Mientras
que el de secuencia muestra el aspecto de ordenamiento
temporal, de cómo se suceden estos mensajes entre los objetos.
El diagrama de colaboración es una expresión sintáctica de igual
valor semántico que el diagrama de secuencia; sólo cambia la
forma de exhibirse dicho significado. Un diagrama de
colaboración tiene roles expresados por los objetos y los enlaces
por donde pasarán los mensajes, desde una instancia de un
objeto a otra instancia de otro objeto, que intervienen en la
interacción, (esto es visto como la parte estática de la
colaboración), mientras que la parte dinámica está expresada por
las interacciones expresadas en los flujos de mensajes de la
colaboración. Si en el diagrama de colaboraciones no hubieran
flechas expresando el orden en los mensajes son ejecutados,
podrían verse como una interacción sin considerar aspectos
temporales.

Diagrama de Colaboración
P a n ta l l a
4 . M o s tr a r P e ti c i ò n
9 . M o s tr a r P e ti c i ò n
1 . I n t r o d u c ir T a rj e ta
C l i e n te L e c to r a
5 . E s p e c if i c a r P I N
1 0 . I n f o r m a r C a n ti d a d
2 . T a r j e ta In tr o d u c i d a ( ID )
3 . S o l i c i ta r P IN
te c l a d o d is p e n s e 8 . S o l i c i ta r C a n ti d a d
r
6 . P a s a r P IN
1 1 . I n f o r m a r C a n t i d a1d2 . V e r S a l d o
Id e n ti fi c a
7 . S o l i c i ta r V a l i d a c i ô n P IN c iò n
1 3 . S o l i c i ta r C a n ti d a d ( C )
T ra n s a c c i
o n e s

Diagrama de Secuencia
C liente Lectora Pan talla tecla do Iden tific aciòn dis pen s er Tran s acciones
In troducir Tarjeta
Tarje ta Intro ducida (ID )
Sol icitar PIN
Mos trar Pe ticiò n
Es pecificar PIN
Pa s ar PIN
So licitar Va lida ciôn PIN
Solicitar C a ntidad
Mos trar Pe ticiò n
Info rm a r C antidad
Inform ar C an tida d
Ver Saldo
Solicitar C antidad (C )

Colaboraciones
Definición: dentro del
contexto de Arquitectura de
un sistema, una colaboración
permite nombrar a un bloque
conceptual que incluye
aspectos dinámicos como
estáticos. Es una sociedad de
clases, y otros tipos de
elementos que colaboran
para un comportamiento
cooperativo común, que
siempre es más que las suma
de los comportamientos de
los elementos que la
componen.

Las Colaboraciones especifican la
Realización de Casos de Uso y
operaciones
Validación
Una colaboración puede
Realizar cualquier tipo de
clasificador, incluyendo
clases, casos de uso,
interfaces, componentes y
nodos.
Pueden agruparse en
paquetes, siempre que los
<<Caso de Uso>> sistemas sean grandes.
Validar Usario

La parte estructural de una colaboración se encuentra
expresada generalmente en un diagrama de clases. No
se debe confundir la colaboración con un paquete , este
es físico mientras que la colaboración es un concepto.
La parte de comportamiento de una colaboración
siempre se expresa en un diagrama de interacción.
Existe el concepto de Refinamiento entre

colaboraciones, por lo tanto una colaboración, puede
refinar o ser refinada por otra y al mismo tiempo
realizar a un Caso de Uso.
Hacer Pedido refinamiento
Validación de pedidos
Realización
Gestión de Pedidos

Patrones y frameworks
Patrón.
Definición: un patrón proporciona un solución común a
un problema común en un contexto dado. Los patrones
ayudan a visualizar, especificar, construir, y documentar
los distintos rastros o artefactos de un sistema. Los
patrones pueden ser de diseño, (mecanismo), o de
arquitectura, (framework). Un framework integra uno o
varios mecanismos.
fram ework Rec epciòn de pedidos
M ec anis m o Fac turac iòn
M ecanis m o Com probac iòn

Son soluciones concretas. Proponen soluciones a

problemas concretos, no son teorías genéricas.
•Son soluciones técnicas. Indican resoluciones
técnicas basadas en Programación Orientada a
Objetos (POO). En ocasiones tienen más utilidad con
algunos lenguajes de programación y en otras son
aplicables a cualquier lenguaje.
•Se utilizan en situaciones frecuentes. Ya que se
basan en la experiencia acumulada la resolver
problemas reiterativos.
•Favorecen la reutilización de código. Ayudan a
contruir software basado en la reutilización, a construir
clases reutilizables. Los propios patrones se reutilizan
cada vez que se vuelven a aplicar.

•Es dificil reutilizar la implementación de un patrón.

Al aplicar un patron aparecen clases concretas que
soluciónan un problema concreto y que no será aplicable a
otros problemas que requieran el mismo patrón: Una
ventana es una solución para ventilar e iluminar un
habitáculo, pero la ventana de mi casa no es util en el
camarote de un barco.
•El uso de un patrón no se refleja en el código. Al
aplicar un patrón, el código resultante no tiene por que
delatar el patrón o patrones que lo inspiró. No obstante
últimamente hay múltiples esfuerzos enfocados a la
construcción de herramientas de desarrollo basados en los
patrones y frecuentemente se incluye en los nombres de las
clases el nombre del patrón en que se basan facilitando así
la comunicación entre desarrolladores.
Mecanismo.
Definición: un mecanismo es un patrón de diseño
que se aplica a una sociedad de clases, o sea a una
colaboración, y especifican la estructura y el
comportamiento de una sociedad de clases. (1.) Se
modelan como colaboraciones simples, ya que dan
tan sólo un nombre a la sociedad de clases. Por otra
parte una clase puede ser miembro de varias
colaboraciones simultaneamente.
Un mecanismo puede nombrar una plantilla

formada por un conjunto de abstracciones que
colaboran entre sí para un objetivo común. Esto se
ve como una colaboración parametrizada,
(concepto relacionado con una clase
plantilla),(2.).1
< < Cliente> >

Cliente
A plic ac iòn
Orden
Emisor
Receptor
< < Rec eptor> >

D ocum ento
Ordenar
< < orden> > < < Orden> > < < E m is or> >
OrdenA brir OrdenP egar M enùItem

Dentro de un determinado patrón de diseño,

(mecanismo), :
• Identificar la solución al problema común y la
materializarla como un mecanismo.
• Modelar el mecanismo como una colaboración,

determinando sus aspectos estructurales y de
comportamiento.
• Identificar los elementos del patrón de diseño que

deben ser ligados a elementos concretos en un
contexto específico y mostrarlos como parámetros de
la colaboración.

Clasificación según su propósito:
•Patrones de Creación: Tratan la creación de
instancias.
•Patrones Estructurales: Tratan la relación entre

clases, la combinación clases y la formación de
estructuras de mayor complejidad.
•Patrones de Comportamiento: Tratan la
interacción y cooperación entre clases.
Clasificación según su ámbito:

•De clase: Basados en la herencia de clases.
•De objeto: Basados en la utilización dinámica de

objetos.
Framework. (armazones).
Es típicamente un patrón arquitectónico que
proporciona una plantilla extensible para
aplicaciones dentro de un dominio. Especifican la
estructura y el comportamiento de un sistema
completo. Contiene abstracciones que las
abstracciones del desarrollador puede instanciar
o invocar
Los armazones están bastante relacionados
con los Patrones. Un armazón es un modelo
arquitectónico que describe una estructura de
software fácilmente ampliable y reutilizable.
Formas de descomponer, conectar y
relacionar sistemas, trata conceptos como:
niveles, tuberías y filtros. Es un nivel de
abstracción mayor que el de los Patrones de
07/04/2005
Diseño.
Lic. Daniel Rubén Fernández Iriart 112
Otros patrones.....
•Patrones de Programación (Idioms Patterns).

Patrones de bajo nivel acerca de un lenguaje de
programación concreto, describen como implementar
cuestiones concretas.
•Patrones de Analisis. Conjunto de reglas que permiten

modelar un sistema de forma satisfactoria.
•Patrones de Organizacionales. Describen como

organizar grupos humanos, generalmente relacionados con
el software.
•Otros Patrones de Software. Se puede hablar de

patrones de Programación concurrente, de Interfaz Gráfica,
de Organización de Código, de Optimización de Código, de
Robustez de Código, de Fase de Prueba.

UMLcurso

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UMLcurso

Cargado por

Copyright:

Formatos disponibles

Lenguaje

¾Muchas veces, ciertas cosas, en cuanto de sistemas de

¾Un modelo explicita lo que queremos expresar

07/04/2005 Lic. Daniel Rubén Fernández Iriart 3

Agregacion: Auna fuerte

Permite la ingeniería directa e inversa +

Use-Case Diagram Class Diagram State Diagram add file

Use Case 1 add( )

Use Case 3 withdraw()

MFC Class Diagram

ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

Definition mainWnd : MainWnd Windows

1: Doc view request ( ) L

4: create ( ) gFile : GrpFile

user : »ç¿ëÀÚ GraphicFile IBM

È-ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â 6: fillDocument ( )

È-¸é °´Ã¼´Â ÀÐ¾îµéÀÎ 9: sortByName ( )

07/04/2005 Lic. Daniel Rubén Fernández Iriart 8

Alcance Æ El contexto que da un significado específico a un nombre.

VisibilidadÆ Cómo se pueden ver y utilizar esos nombres por otros.

IntegridadÆ Cómo se relacionan apropiada y consistentemente unos

Ejecución Æ Qué significa ejecutar o simular un modelo dinámico.

Un ¨modelo bien formado¨, es aquél que es semánticamente

07/04/2005 Lic. Daniel Rubén Fernández Iriart 10

Restricciones: permiten agregar nuevas reglas y/o

07/04/2005 Lic. Daniel Rubén Fernández Iriart 13

Definición: una relación es una conexión entre elementos.

nodo clase activa

Use-Case Diagram Class Diagram State Diagram add file

MFC Class Diagram

ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

Definition mainWnd : MainWnd Windows

1: Doc view request ( ) L

user : »ç¿ëÀÚ GraphicFile IBM

fileMgr : FileMgr Mainframe

È-ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â 6: fillDocument ( )

È-¸é °´Ã¼´Â ÀÐ¾îµéÀÎ 9: sortByName ( )

c o m p ra rE n t ra d a s ve n d e d o r Introd u cir Tarje ta

Mos trar Peticiòn

Mos trar Peticiòn

Un componente puede implementar varias clases,

< < I n t e rf a c e > >

< < In t e r f ac e> >

13/11/2003 v e n d e r(c :c lie n t e )()

tanque lleno( cierra canilla )

Valvula Valvula Vista dinámica de

< < in c lu d e > >

Los diagramas son vistas del modelo

22/11/2003 Lic. Daniel Rubén Fernández Iriart 48

07/04/2005 Lic. Daniel Rubén Fernández Iriart 24

07/04/2005 Lic. Daniel Rubén Fernández Iriart 25

Elementos Relaciones Diagramas

07/04/2005 Lic. Daniel Rubén Fernández Iriart 26

07/04/2005 Lic. Daniel Rubén Fernández Iriart 27

Estructurales Comportamiento Agrupación Anotación

07/04/2005 Lic. Daniel Rubén Fernández Iriart 28

nodo clase activa

07/04/2005 Lic. Daniel Rubén Fernández Iriart 30

07/04/2005 Lic. Daniel Rubén Fernández Iriart 31

07/04/2005 Lic. Daniel Rubén Fernández Iriart 32

07/04/2005 Lic. Daniel Rubén Fernández Iriart 33

07/04/2005 Lic. Daniel Rubén Fernández Iriart 34

07/04/2005 Lic. Daniel Rubén Fernández Iriart 35

07/04/2005 Lic. Daniel Rubén Fernández Iriart 36

Alcance Æ El contexto que da un significado específico a un nombre.

VisibilidadÆ Cómo se pueden ver y utilizar esos nombres por otros.

IntegridadÆ Cómo se relacionan apropiada y consistentemente unos

Ejecución Æ Qué significa ejecutar o simular un modelo dinámico.