Analisis y Diseo Orientado A Objetos

ANLISIS Y DISEO
ORIENTADO A OBJETOS
(ADOO)
CON UML
Alejandro Domnguez / Jorge
Kashiwamoto / Enrique Torres
(Versin 4.0)
Curso impartido en la Fundacin Arturo
Rosenblueth y en UNITEC de 1998-2010
Objetivos generales
Proporcionar el conocimiento de los
principios inherentes en el anlisis y diseo
orientado a objetos
Introducir el Lenguaje Unificado de
Modelado (Unified Modeling Language:
UML), el cual es el lenguaje estndar para
el anlisis y diseo orientado a objetos
Utilizar UML para modelar un caso prctico
de sistemas
Panormica general del curso

(1)
El curso en 13 captulos
Captulo 1: Tratamiento de la complejidad y la
orientacin a objetos
Captulo 2: Historia de la orientacin a objetos

Captulo 3: Conceptos de la orientacin a
objetos
Captulo 4: Introduccin a UML y al anlisis y
diseo orientado a objetos
Captulo 5: Modelo de requerimientos
(modelado de casos de uso)
3

(2)
El curso est compuesto por ...
Captulo 6: Modelo de anlisis (diagramas de clase)
Captulo 7: Modelo de diseo (diagramas de
secuencia)
Captulo 8: Modelo de diseo (diagramas de estado)

colaboracin)
actividad)
Captulo 11: Modelo de implantacin (diagramas de
componentes)
Captulo 12: Modelo de implantacin (diagramas de

deployment)
Captulo 13: Introduccin al proceso unificado de
desarrollo de software

(2)
El curso est compuesto por ...
Captulo 13: Introduccin al Proceso
Unificado de
Desarrollo de Software
RUP

(3)
Adicionalmente el alumno debe cubrir de forma
autodidacta el aprendizaje de la herramienta
Rational Rose o Visio de las partes 4 a 12
Se puede obtener una versin de evaluacin de Rational
Rose por 30 das en http://www.rational.com
En clase se presentarn algunos ejemplos para

facilitar la comprensin de la elaboracin de
diagramas.
Material de consulta (1)

Alejandro Domnguez
Anlisis y Diseo Orientado a

Objetos con UML Versin 3.0
FAR
Booch, G., J. Rumbaugh y I.

Jacobson. The unified modeling
language user guide. AddisonWesley, 1999.
Fowler, M. Y K. Scott. UML gota a
gota. Pearson, 1999.
Oestereich, B. Developing software
with UML. Addison-Wesley, 1999.

Schneider, G. y J.P. Winters.
Applying use cases. AddisonWesley, 1999.
Taylor, D.A. Object technology.
Addison-Wesley, 1998.
Rational Software, 1997. UML
notation guide. Version 1.1.

http://www.rational.com
Rational Software, 1997. UML
semantics. Version 1.3.
http://www.rational.com
8

Booch, G., J. Rumbaugh y I. Jacobson. The
unified modeling language reference guide.
Addison-Wesley, 1999.
Larman, C. / UML y Patrones / Pearson / 1999
Rumbaugh / OMT / Addison-Wesley
Booch, G., J. Rumbaugh y I. Jacobson. El

Proceso Unificado de Desarrollo de
Software. Addison-Wesley, 1999.
Evaluacin del curso

100% anlisis y diseo de un caso prctico
de sistemas que incluya:
Diagramas de casos de uso
Diagramas de clase
Diagramas de secuencia
Diagramas de estado
10
TRATAMIENTO DE LA
COMPLEJIDAD Y LA
ORIENTACIN A OBJETOS
Alejandro Domnguez
11
Panormica general
Complejidad de los sistemas de
software
Tratamiento de la complejidad y
descomposicin
Descomposicin orientada a
procesos y a objetos
12
Los sistemas
Un sistema es:
Un grupo conexo y organizado de objetos
Un todo compuesto de partes organizadas
acorde a algn esquema o plan
Los sistemas tienen:

Fronteras
Entorno
Caractersticas propias
Propiedades emergentes
13
Sistemas complejos
La complejidad de
un sistema es una
propiedad inherente,
no accidental
La interconexin de
los sistemas es una
fuente potencial para
inconsistencias e
incongruencias
14
Origen de la complejidad de
los sistemas
Desarrollado por personas
Sujeto a cambios
Desarrollado a travs de
un proceso largo y tedioso
La no existencia de leyes
fundamentales para
explicar los fenmenos y
enfoques
No se comprende el
sistema en su totalidad
Difcil de documentar y
probar
Potencialmente
inconsistente o incompleto
Existencia del Lmite de

Miller
El ser humano slo puede
manejar, procesar o
mantener la pista de
aproximadamente 7
objetos, entidades o
conceptos a la vez
15
4 razones para la complejidad

(Grady Booch)
1 razn.- La naturaleza del
dominio del problema:
Requerimientos complejos
Decaimiento de los sistemas
2 razn.- Complejidad de
los procesos:
Problemas en la
administracin y gestin
Necesidad de simplificacin
16
4 razones para la complejidad

(Grady Booch)
3 razn.- La flexibilidad
de los sistemas es un
arma de dos filos
4 razn.- Caracterizar el
comportamiento discreto
de los sistemas:
Existencia de varios
estados
Dificultad para explorar
todos los estados
17
5 atributos de los sistemas

complejos (Grady Booch)
1er atributo
Los subsistemas son jerrquicos e interactuan
entre ellos
2 atributo
Los subsistemas se han definido arbitrariamente
3er atributo
El acoplamiento entre componentes del mismo
subsistema es fuerte y el acoplamiento entre
componentes de diferentes subsistemas es dbil
18
5 atributos de los sistemas

complejos (Grady Booch)
4 atributo
Poseen una serie de subsistemas recurrentes que
aparecen en diferentes combinaciones y arreglos
5 atributo
No siempre evolucionaron de sistemas simples a
sistemas complejos
19
Tratamiento de la
complejidad
Principios que permitirn el
tratamiento de la complejidad:
Abstraccin
Ignorar los detalles no esenciales y
construir un modelo ideal y generalizado
Jerarqua
Clasificar en grupos de abstracciones
relacionadas para poder distinguir
explcitamente las propiedades comunes y
distintas
Descomposicin
Orientada a procesos
Orientada a objetos
20
Descomposicin
La mejor tcnica conocida
desde tiempos inmemoriales
para enfrentar la
complejidad es: divide et
impera
Con esta tcnica se solventa

la restriccin impuesta por el
lmite de Miller
21
procesos (OP)
Se aplica para descomponer un

problema en pequeos pasos o
procesos
La unidad fundamental de este
tipo de descomposicin es el
subproceso
El proceso resultante toma la

forma de un rbol en el que cada
subproceso realiza su trabajo,
llamando a otro subproceso
22
objetos (OO)
El sistema se visualiza como un conjunto de
objetos autnomos, que al colaborar entre
si muestran cierta conducta
Los procesos no existen de manera
independiente, estn asociados a las objetos
Cada objeto exhibe un comportamiento
propio bien definido, y adems modela
alguna entidad del mundo real
23
Descomposicin OP vs OO
Cul es la forma correcta de descomponer
un sistema complejo, OP u OO?
Las dos formas son importantes
La OP muestra el orden de los eventos
La OO enfatiza las entidades que causan la
accin
No es recomendable descomponer un
sistema complejo de ambas formas
simultneamente debido a que se
incrementa la complejidad
24
Recomendacin para el
tratamiento de la complejidad
Primero aplicar un descomposicin OO, la
cual servir como marco de referencia para
continuar con una descomposicin OP
25
HISTORIA DE LA
ORIENTACIN A
OBJETOS
Alejandro Domnguez
26
Panormica general
La vida media de las tecnologas
de IS
Aspectos histricos de la
orientacin a objetos(OO)
La OO en lo 1990s
Lo que se ha aprendido de la OO
27
15 aos de fama
La experiencia nos dice que las tecnologas
de ingeniera de software (IS) ms
populares tienen el siguiente
comportamiento:
Toman algn tiempo en llegar a ser populares
Tienen un periodo de florecimiento de 15 aos
Un ejemplo es la metodologa estructurada

Empez a ser popular entre de 1973-1975
Alcanz su pico de popularidad entre 1985-1989

28
La vida media para las

tecnologas de IS
La vida media para las tecnologas indica el
punto medio en su ciclo de vida
La vida media en la orientacin a objetos
significa que:
Se ha utilizado esta tecnologa por algn tiempo
en proyectos reales
Ser remplazada por otras tecnologas dentro de
un periodo de 7 a 10 aos
29
Aspectos histricos (1)

1963:
I. Sutherland disea Sketchpad en el cual se
presentan grficas e interfaces grficas de usuario
OO; as como clases (masters) e instancias
1966:
Se introduce al mercado Simula, el primer
lenguaje de programacin OO
Finales de 1960s:
Alan Kay trabaja en la mquina denominada
FLEX, la precursora de Dynabook, la Xerox
Star, y la Apple Macintosh
30

1970:
El trmino orientado a objetos se introduce en
la literatura. Muchas personas se lo acreditan a
Alan Kay
1972:
Se desarrolla la primera versin de Smalltalk
1980:
Grady Booch introduce el diseo orientado
objetos
Se introducen las primeras versiones de
hardware OO
31

1985:
aparecen las bases de datos OO
aparecen la bibliotecas de clases OO
1986:
Se introducen las primeras versiones de
anlisis OO y de anlisis de
requerimientos OO
1988:
anlisis del dominio OO aparece en la
literatura
32

1980s:
Se desarrollan un gran cantidad de
aplicaciones OO
Estas aplicaciones son principalmente
aplicaciones de tiempo real
Literalmente, se producen millones de lneas
de cdigo OO
Finales de 1980s:
Aparece un gran nmero de lenguajes de
programacin OO; incluyendo: C++,
Eiffel, CLOS, etc.
33

Algol
No orientado
a objetos
Fortran
Orientado
a objetos
LISP
1960
Cobol
PL/1
Simula
Smalltalk-72
1970
Prolog
Smalltalk-74
Pascal
Smalltalk-76
Smalltalk-78
Loops
Smalltalk-80
1980
Ada
Objective C
Object Pascal
C ++
Eiffel
1990
Ada 9
Object Cobol
Java
CLOS
34
Mediados de los 1990s (1)

La MOO empieza a mostrar signos de
vida media:
Literalmente cientos de millones de lneas
de cdigo fuente OO se han escrito
Algunos productos OO contienen alrededor de
2,000,000 de lneas de cdigo
La tecnologa de BDOO tiene un xito sin

precedente
La Object Management Group (OMG) hace un
esfuerzo por estandarizar la tecnologa de
BDOO
El mercado de los sistemas de bases de datos
OO se duplica cada ao
35

La MOO empieza a mostrar signos de vida
media:
Los desarrolladores de software pueden elegir
entre un gran nmero de herramientas CASE OO
Object Internationals Object Tool
Rationals Rose
Protosofts Paradigm Plus
Existen muchos enfoques de desarrollo de

software OO: Booch, Rumbaugh, Coad, WirfsBrock, Berard, Fusion, Shlaer-Mellor, ...
Alrededor de 30 enfoques son populares
36

La MOO empieza a mostrar signos
de vida media:
El trmino orientado a objetos
aparece de forma regular en las
publicaciones de negocios: The Wall
Street Journal, Business Week, ...
La comunidad de administracin de
los SI empieza a utilizar la tecnologa
OO
37

OOSA
Shalaer/Mellor
Ada/Booch
Booch 91
Booch
1990
OOSE
Jacobsen
RDD
Wirfs-Brock
OMT
Rumbaugh et al.
OBA
Gibson/Goldb.
OOA
Coad/Yourdon
Booch 93
OOSE 94
1995
1997
State Charts
Harel
OMT 94
Fusion
Coleman
SOMA
Graham
Team Fusion
Coleman et al.
OODA
Martin/Odell
MOSES
Henderson-Sellers
RD
Shalaer/Mellor
38
A finales de los 1990s

Existe una tendencia a estandarizar
las tecnologas orientadas a objetos
Unified modeling language (UML)
Business objects
Existe un crecimiento significante

(y explosivo) de tecnologas
basadas en la orientacin a objetos
programacin basada en componentes
programacin basada en agentes
39
Lo que se ha aprendido (1)

La tecnologa OO es una
oportunidad, no una garanta
Los proyectos orientados a objetos
pueden fallar
La tecnologa OO es vasta
Ms amplia que lo indicado en los
lenguajes de programacin OO
40

La evidencia emprica muestra que,
cuando se compara con las mismas
aplicaciones desarrolladas utilizando
enfoques tradicionales, las soluciones
OO
Son ms pequeas
Son menos complejas
Son ms apropiadas para aplicaciones de
tiempo real
Toman menos tiempo en desarrollarse
41

La tecnologa OO hace mas nfasis
en la reusabilidad del software que
los mtodos tradicionales
Sin embargo muy pocas personas
dentro de la comunidad OO entiende
lo que verdaderamente significa
reusabilidad
42

La tecnologa OO tiene impacto en
los dominios de:
Las practicas administrativas
Las metodologas del ciclo de vida
La seleccin de herramientas
El almacenamiento persistente
Los lenguajes de programacin
43
CONCEPTOS DE LA
ORIENTACIN A
OBJETOS
Jorge Kashiwamoto /
Alejandro Domnguez
44
Panormica general
La orientacin a objetos
Objetos y abstraccin
Clasificacin y clases
Caractersticas de los Objetos
Relaciones
Agregacin
Modularidad
Encapsulamiento
Generalizacin y especializacin
Polimorfismo
Herencia y herencia mltiple

Conclusiones
45
Qu es la Orientacin a
Objetos?
46
Paradigma
PARADIGMA
Procedural
Funcional
ASPECTOS ESENCIALES
QUE MODELA
Algoritmos
Restricciones
Metas u objetivos en un clculo

de predicado
Relaciones invariantes
Objetos
Clases y objetos
47
Paradigma de la
ORIENTACIN A OBJETOS
Marco conceptual propio
Anlisis de problemas
Enfoque particular del problema.
Planteamiento ms claro
Determinados problemas
Determinado marco conceptual
Apropiado para el desarrollo de aplicaciones

comnes
Donde el anlisis de la complejidad juega el papel

ms importante
48
Derivados de la OO
Tecnologas
Metodologas
Programacin
Lenguajes
Bases de Datos
Etc.
49
Motivaciones de la OO
Tratar o abordar dominios de problemas ms amplios y
complejos
Mejorar la interaccin entre los usuarios y los analistas.
Incrementar la
programacin
consistencia
entre
anlisis,
diseo
Representar explcitamente los aspectos comunes dentro de

una clase o familia de entidades.
Construir especificaciones fciles de cambiar o adaptar

Reusar resultados previos de anlisis, diseo y programacin
Proveer una representacin subyacente consistente para el
anlisis, el diseo y la programacin
50
Orientacin a Objetos
El software se organiza como una coleccin
de objetos discretos que contienen tanto
estructuras de datos como comportamiento
Rumbaugh
Los objetos renen las caractersticas

esenciales que los definen.
51
La orientacin a objetos (OO)

Significa notaciones, tcnicas y mtodos
para producir varios modelos de un
sistema en diferentes niveles de
abstraccin y granularidad basados en los
principios de:
Objetos
Clases de objetos
Encapsulamiento
Herencia
Polimorfismo
52
Definicin de objeto
Un objeto es:
Diccionario Larousse: Objeto (del bajo latn
objectum < lat.)
Cosa material y concreta, por lo regular de dimensiones
reducidas
Trmino con lo que se denota aquello sobre lo que
recae la accin expresada por el verbo
The 3 amigos:
Una manifestacin concreta de una abstraccin
Una entidad con una frontera e identidad bien definidas
que encapsula estado y comportamiento
Una instancia de una clase
53
OBJETO
Es una entidad que retiene una cierta informacin
abstracta y sabe como realizar ciertas operaciones sobre
esta informacin
Wirfs-Brock
OBJETO =
ATRIBUTOS +
COMPORTAMIENTO
Entidad discreta con lmites e identidad bien delimitadas

que encapsula el estado y el comportamiento. Instancia
de una clase.
UML
54
Ejemplos de objetos
En una empresa
procesadora de
alimentos
Objetos pasivos:
Un saco de lentejas
Un paquete de caf
Factura 895 enviada a
alguna empresa
Agentes humanos
Zoila Baca del Corral
(Secretaria ejecutiva)
Armando B. Roncas
(Guardia de seguridad)
Objetos estructurales
Departamento de
ventas
Objetos activos:
Camioneta placas
1234AB
La mquina de fax de
la empresa
55
Abstraccin
La abstraccin surge desde un
reconocimiento de similaridades entre ciertos
objetos, situaciones o procesos en el mundo
real, y la decisin de concentrar la atencin
sobre estas similaridades e ignorar por el
momento las diferencias.[Hoare]
La
abstraccin
es
una
descripcin
simplificada, o especificacin, de un sistema
que enfatiza algunos de los detalles o
propiedades del sistema mientras suprime
otras. Una buena abstraccin es una que
enfatiza detalles que son significativos al
lector o usuario y suprime detalles que son,
al menos por el momento, inmateriales o que
distraen la atencin. [Shaw]
56
Abstraccin
Un concepto califica como una abstraccin
slo si este puede ser descrito, comprendido
y
analizado
independientemente
del
mecanismo que eventualmente ser usado
para realizar ste. [Berzins, Gray y
Naumann]
Una abstraccin denota las caractersticas
esenciales de un objeto que distinguen a ste
de todos los otros tipos de objetos y de esta
forma proporciona lmites conceptuales
definidos sucintamente, relativos a la
perspectiva del observador. [Booch]
57
Abstraccin
Abstraccin es el principio de ignorar
aquellos aspectos de un sujeto que no son
relevantes al propsito actual, con el objetivo
de concentrar la atencin completamente en
aquellos que lo son. [Oxford University]
La abstraccin de datos es el principio de
definir un tipo de dato en trminos de las
operaciones que se aplican a objetos de este
tipo, con la restriccin de que los valores de
tales objetos pueden ser modificados y
observados slo mediante el uso de estas
operaciones. [Oxford University]
58
Abstraccin (Resumen 1/2)

Forma fundamental en que los seres
humanos se enfrentan con la complejidad
de los problemas del mundo circundante.
Una abstraccin denota las caractersticas
esenciales de un objeto, distinguindolo de
otros tipos de objetos y obviando
caractersticas irrelevantes a los intereses
del observador que hace la abstraccin
59
Abstraccin (Resumen 2/2)

Segn Booch
Una abstraccin denota las caractersticas esenciales de
un objeto que lo distingue de todos los dems y, por lo
tanto, proporciona fronteras conceptuales definidas,
relativas a la perspectiva del observador
Lo que un observador concibe no necesariamente

lo concibe un observador diferente
60
Clasificacin
Los
objetos
con
iguales
estructuras
y
comportamiento (operaciones) se agrupan para
formar una clase que los describe.
En este sentido el concepto de clase nos permite
dividir y clasificar los objetos de nuestro problema.
Se dice que la clase en tanto describe funciona
como el tipo y el objeto en tanto es descrito y
puede tener una existencia concreta, como la
instancia o variable del tipo.
CLASES
61
Dificultades de la clasificacin
62
CLASE
Es una coleccin de objetos los cuales comparten
las mismas caractersticas y comportamientos.
Wirfs-Brock
Descriptor para un conjunto de objetos que

comparten los mismos atributos, operaciones,
mtodos, relaciones y comportamiento. Concepto
del sistema modelado.
UML
63
Representacin de clase
64
Tipo de dato abstracto

Abstract Data Type (ADT)
Un tipo de dato abstracto es una caracterizacin
precisa de una entidad en termino de atributos y
operaciones, la cual brinda una interfaz y una
implementacin.
Su interfaz es el medio de comunicacin con el

exterior, donde se describe la forma en que deben
ser invocada cada una de las operaciones, mientras
que
su
implementacin
consiste
en
la
representacin interna que tengan cada uno de los
atributos, as como la forma concreta en que cada
una de las operaciones acta sobre dichos
atributos. La implementacin es una parte oculta al
usuario del ADT, un mismo ADT puede tener varias
implementaciones pero una nica interface.
65
Ejemplo de Pila (abstraccin)

programacin en C con
abstraccin
programacin en C muy primitiva
typedef int T;
# define Max_Stack 100
T stack[Max_Stack];
int top=0;
T item;
typedef int T;
typedef struct{
int top, size;
T *stack;
}stack;
/* Interface para el manejo de la pila */

int create(int size);
int destroy(void);
void push(T new_item);
void pop(T *old_top);
void top(T *cur_top);
int is_empty(void);
int is_full(void);
int stack_create(stack *s, int size);

void stack_destroy(stack *s);
void stack_push(stack *s, T item );
void stack_pop(stack *s, T *item);
int stack_is_empty(stack *s);
int stack_is_full(stack *s);
2
66
Ejemplo de Pila (ADT)

Programacin en C++ con
abstraccin en Objectos
Abstraccin y genericidad usando

POO
typedef int T;
class stack{
public: //interface
stack(int size);
~stack(void);
void push(const T &item);
void pop(T &item);
int is_empty(void) const;
int is_full(void) const;
private: //implementacin
int top_, size_;
T *stack;
}
stack s1(10); s1.push(473);
template <class T>

class stack{
public: //interface
stack(int size);
~stack(void);
void push(const T &item);
void pop(T &item);
int is_empty(void) const;
int is_full(void) const;
private: //implementacin
int top_, size_;
T *stack;
}
stack<int> s1(10); s1.push(10);
stack<empleado> s2(20);
s2.push(juan);
67
Caractersticas de un objeto
Abstraccin /
Clasificacin
Encapsulamiento
Herencia
Polimorifismo
Modularidad
Extensibilidad
Persistencia
Concurrencia
Identidad
Estado
Reusabilidad
Comportamiento
68
Caractersticas bsicas de los

objetos
Un objeto tiene
Estado
Comportamiento
Identidad
69
Estado
Una condicin o situacin durante la
vida de un objeto que satisface
alguna condicin, lleva a cabo
alguna actividad, o espera algn
evento
Transicin
Cambio de estado.
Evento
Un suceso u ocurrencia de un fenmeno
que lleva a una transicin.
70
Comportamiento
Los efectos observables de un
evento, incluyendo sus
resultados
71
Comportamiento:
Implantacin
Operacin
Es una funcin de transformacin sobre los atributos del
objeto (no necesariamente cambindolos). Los tipos ms
comunes de operacin sobre un objeto son: Modificacin,
Seleccin, Iteracin.
Mtodo
Es la implementacin especfica de una operacin. Algunos
especialistas utilizan los trminos Operacin y Mtodo de
manera intercambiable.
72
Comportamiento:
Tipo de Objetos
Objetos Activos y Objetos Pasivos
Los objetos activos son aquellos que dirigen su propio hilo
de control. Los objetos pasivos slo pueden ejecutar
transiciones cuando se acta sobre ellos. Dado que los
objetos activos son autnomos, ellos son la raz del control
en un sistema. La existencia de hilos mltiples de control
en un programa (concurrencia) slo puede lograrse con
mltiples objetos activos, mientras que los sistemas
secuenciales slo tienen un objeto activo a la vez.
Objeto Cliente y Objeto Servidor

El objeto servidor responde a una solicitud de servicio
(mensaje) del objeto cliente. Se establece una relacin de
contrato cliente-servidor. Segn este contrato el servidor
debe cumplir las responsabilidades que se le exigen en el
mismo.
73
Identidad
Propiedad que permite
distinguirlo de todos los
dems objetos
existentes
74
Identidad
Los datos estn cuantificados en entidades
discretas y distinguibles, con fronteras bien
definidas, denominadas objetos.
Cada objeto tendr una existencia propia,
independientemente del valor de sus atributos.
No es diferenciar los objetos por su nombre, sino
ellos mismos, por el hecho de existir.
Todo objeto contiene una referencia a si mismo.
Ejemplo
clasedefinida a,b
a <> b
75
Propiedades de los objetos

(1)
Atributos
Son la estructura de los objetos: sus
componentes y la informacin o datos
contenidos en l
Son las caractersticas o propiedades intrnsecas o
internas de los objetos
Son pares del tipo nombre: valor

El nombre debe reflejar la semntica de la
caracterstica o propiedad que representa
El nombre se utiliza para accesar el valor de la
caracterstica del objeto
El valor de los atributos puede cambiar en el tiempo,
pero este no es el caso del nombre
Determinan el estado del objeto
76

(2)
Operaciones
Son servicios que pueden realizar los
objetos cuando se les enva un
mensaje
Determinan el comportamiento de los
objetos
Algunas veces se utilizan las palabras
servicios o mtodos o
errneamente procedimientos o
funciones
77

(3)
Restricciones
Son condiciones,
requerimientos y reglas que
deben satisfacer los objetos
Restringen las propiedades
y estados de los objetos
Regularmente estn
determinadas por los
valores que pueden tomar
los atributos
78
Ejemplo: un circulo
Nombre: circulo
Atributos: radio (radio:r) y
posicin del centro (centro:(a,b))
Operaciones: desplegar,
remover, reposicionar, modificar
tamao
Restricciones: el radio debe ser
positivo
79
Modularidad
"La accin de particionar un programa en componentes

individuales
puede
reducir
su
complejidad
en
algn
grado...".[Myers]
"La modularizacin consiste en el hecho de dividir un programa en

mdulos los cuales puedan ser compilados separadamente, pero
stos tienen conexiones con otros mdulos". [Liskov]
"Las conexiones entre los mdulos son las asunciones que los
mdulos hacen acerca de cada otro". [Parnas]
" Modularidad es la propiedad de un sistema que ha sido

descompuesto
en un conjunto de mdulos acoplados
coherentemente y libremente". [Booch]
"La meta global de la descomposicin en mdulos es la reduccin

del costo del software al permitir que los mdulos sean diseados
y revisados independientemente... La estructura de un mdulo
debe ser lo suficientemente simple de forma tal que sta pueda ser
comprendida completamente; debe ser posible cambiar la
implementacin de unos mdulos sin la necesidad de conocer de la
implementacin
de
otros
mdulos
y
sin
afectar
su
comportamiento".
80
Modularidad
Principio de programacin que nos permite precisar las
interfaces con distintas decisiones de diseo.
Los mdulos son una forma de organizar y especializar el
trabajo de programacin.
Deben ir en un mismo mdulo todas aquellas herramientas

que tengan una unidad conceptual y de vocabulario, aquellas
que se refieran al tratamiento de un mismo aspecto.
En la medida en que cada uno de estos aspectos este bien
distinguido y generalizado en un mdulo mayor ser la
utilidad y rango de aplicacin de ste.
Esta forma de pensar nos permite hacer diseos ms amplios
y especializados que rebasan las necesidades de nuestra
aplicacin y nos permiten obtener herramientas ms
duraderas.
Se debe buscar completitud.
81
Encapsulamiento
La abstraccin y el encapsulamiento son conceptos
complementarios: la abstraccin focaliza sobre la
visin externa de un objeto y el encapsulamientotambin conocido como ocultamiento de informacin impide que los clientes vean la visin interna del
objeto, donde el comportamiento de la abstraccin es
implementado. De esta manera, el encapsulamiento
proporciona barreras explcitas entre diferentes
abstracciones.
"Para trabajar la abstraccin, la implementacin debe
ser encapsulada". [Liskov] En la prctica, esto significa
que cada clase debe tener dos partes: una interfaz y
una implementacin. La interfaz de una clase captura
slo su visin externa, encerrando nuestra abstraccin
del comportamiento comn de todas las instancias de
la clase. La implementacin de una clase comprende la
representacin de la abstraccin as como los
mecanismos que alcanzan el comportamiento
deseado.
82
Encapsulamiento
"El encapsulamiento es el proceso de ocultamiento de
todos los detalles de un objeto que no contribuyen a
sus caractersticas esenciales". [Booch] En la prctica,
uno oculta la representacin de un objeto as como la
implementacin de sus mtodos.
"El encapsulamiento (ocultamiento de informacin) es
un principio usado cuando se desarrolla la estructura
global de un programa, donde cada componente de un
programa debe encapsular u ocultar una nica
decisin de diseo...La interfaz de cada mdulo es
definida en forma tal que revele tan poco como sea
posible acerca de su funcionamiento interno. [Oxford
University]
Esto ayuda a un trabajo eficiente de los
programadores de manera que tengan que invertir
pocos esfuerzos a la hora de hacer cambios o
modificaciones.
83
Encapsulamiento (Resumen)
La abstraccin y el encapsulamiento
son conceptos complementarios
La abstraccin se centra en el
comportamiento observable de un objeto
El encapsulamiento se centra en el origen
de dicho comportamiento
El encapsulamiento
Se logra a travs del ocultamiento de la
informacin que no contribuye a sus
caractersticas esenciales de un objeto
84
Ejemplo de encapsulamiento
85
Permisos de Acceso
Publico: Los atributos y operaciones declarados
pblicos (interfaz de la clase) sern del acceso de
cualquier funcin, ya sea sta una operacin en
una clase derivada o en cualquier otra clase cliente
de los servicios de la clase.
Protegido: Los atributos y operaciones declarados
protegidos (implementacin de la clase) sern del
acceso de cualquier funcin que sea una operacin
en una clase derivada.
Privado: Los atributos y operaciones declarados
privados (implementacin de la clase) sern del
acceso slo de las funciones de la propia clase.
86
Permisos de Acceso
Tipos de Clientes
Operaciones en otras clases que invocan operaciones
sobre los objetos de la clase (simples clientes)
mantener el encapsulamiento
Los usuarios no deben tener otra visin de la clase que no
sea la que puede tener a travs de su interface
Operaciones en clases derivadas (clientes privilegiados)

Tener ciertos derechos a conocer ms a fondo los detalles de
implementacin
87
Permisos de Acceso
Rompimiento del Encapsulamiento

Funcionamiento adecuado Permisos de Acceso
Sobre
Atributos privadas
Operaciones privadas
De de la clase base
Causas
Importancia de la Redefinicin
Eficiencia
88
Ejemplo
Circulo
Privado:
Xcoor, Ycoor
Protegido:
radio
Publico:
leer_coor()
mostrar()
ocultar()
esta_oculto()
trasladar()
Circulo expandible
Publico:
Expandir()
Contraer()
89
Clases y funciones amigas

En ocasiones un concepto de diseo (una
funcionalidad) puede ser vista como la interaccin o
el trabajo coordinado de objetos pertenecientes a
ms de una clase.
En este marco podra ser necesario por ejemplo
que las operaciones de cada una de las clases
tuvieran accesos plenos a todos los atributos (a
toda la implementacin) de todas las clases
involucradas .
90
Relacin
Conexin entre cosas
Utilizadas en el modelado OO
Se trazan como rutas con diferentes tipos
de lnea para distinguir diferentes clases de
relaciones.
91
Tipo de Relacin:
DEPENDENCIA
Es una relacin que establece que un
cambio en la especificacin de un objeto
puede afectar otro que lo utiliza, pero no
necesariamente a la inversa.
Tambin conocidas como
Relacin de referencia
asociacin de referencia
92
Dependencia
La conexin slo se refiere a otro objeto
La conexin se lleva a cabo a travs del

paso de mensajes
Un mensaje consiste de 3 partes
Un objeto receptor
Una operacin que el receptor sabe como
ejecutar
Un conjunto ordenado de parmetros que esta
operacin requiere para llevar a cabo su funcin
Parte opcional; si la operacin no necesita informacin
adicional para hacer su trabajo, no existen parmetros
93
Dependencia: ejemplos
Empleado
Atributos
Nombre: Tecla
Puesto: Bibliotecaria
Edad: 40
Salario: 3000.00
Relaciones con
Usuarios
Jefe
Libros
Operaciones
Prestar libros
Reasignar colocaciones
Estar de mal humor
Solicitar aumento de salario
Reasignar colocacin
Vehculo avanzar: 100 km

Receptor
Operacin
Parmetro
94
Dependiencia y dinmica de
los objetos
La dinmica de los objetos se
genera por los mensajes
existentes entre los objetos
El recibir un mensaje provoca
que una operacin sea
ejecutada por el objeto
receptor
La operacin puede mandar
mensajes adicionales a otros
objetos
95
Dependencia: Modelado
Se traza como una lnea punteada dirigida.
Utilice las dependencias cuando se desea mostrar
que un objeto usa a otro.
Frecuentemente se utilizar cuando una clase utliza
a otro como argumento de la firma de una
operacin.
La dependencia puede tener nombre cuando se
requiera calidad por la cantidad de referencias.
96
Ejemplo de Dependiencia
97
Estereotipos de Dependencia
bind
El origen instanca la plantilla destino utilizando los
parmetros actuales
derive
El orrigen puede ser calculado a partir del destino
friend
Especifica que el orgien se le otroga una visibilidad
especial dentro del destino
instanceOf
Especifica que el objeto orgien es una instancia del
clasficador destino
98
Estereotipos de Dependencia
instantiate
El origen crea instancias del destino
powertype
El destino es powertype del origen
Powertype es un clasificador cuyos objetos son hijos de un
padre dado.
refine
Especifica que el orgien es un grado ms fino de
abstraccin que el destino
99
Tipo de Relacin:
GENERALIZACIN
Es una relacin entre una cosa general (superclase
o padre) y una cosa ms especfica (subclase o
hijo).
es-un-tipo-de
Los hijos pueden ser utilizados dondequiera que el
padre aparece.
Herencia
Polimorfismo
Una clase sin padre se llama Raz (root)

Tipos: Herencia Simple y Mltiple
100
Tipo de Relacin: ASOCIACIN

Relacin estructural que especifica que
objetos de una cosa son conectos a
objetos de otra.
Son ligas, conexiones o relaciones entre
un objeto y uno o ms objetos
Existen asociaciones unidireccionales y
bidireccionales, as como estticas y
dinmicas
Relaciones estticas: El acoplamiento de los
objetos perdura por un periodo largo de
tiempo
Relaciones dinmicas: Son aquellas
establecidas por las operaciones
101
Al conectarse 2 clases, se puede navegar

bidireccionalmente. Existe recursividad.
Por el # de clases que conectan

Binarias
n-Elementos
Adornments
Nombre
Rol
Multiplicidad
Agregacin
102
Asociacin: Nombre
Describe la naturaleza y direccin de la
relacin
Persona
TrabajaPara
Empresa
103
Asociacin: Rol
Faceta de la clase en una relacin dada
Los roles pueden ser explcitos

Persona
Empresa
+Empleado
+Empleador
104
Asociacin: Multiplicidad
Cantidad de objetos a ser conectados a
travs de una instancia de la asociacin
Persona
1..*
+Empleador
Empresa
+Empleado
105
Asociacin: Agregacin
Relacin estructural entre puntos
Las dos clases estn al mismo nivel, no hay

una clase ms importante que otra.
Todo/Partes o Contenedor/Contenido
Tiene
Empresa
1
*
Departamento
106
Asociacin: Agregacin
Agregacin
Granja
Crea objetos compuestos a partir

de objetos simples
Es la composicin de un objeto
como un conjunto de partes
Uvalda
Ubre
Lety
Leche
Paty
Pastura
107
Tipos de asociaciones de
agregacin
Existen dos tipos de agregacin
Normal: Es una relacin tiene
Una universidad tiene facultades
Un CD tiene pistas
Nota: Puede faltar alguna de las partes sin
afectar el todo (las partes forman el todo)
Composicin: Es aquella que posee

(contiene) a sus partes (fuerte
dependencia de propiedad)
Un auto contiene motor, llantas, puertas, ...
Un avin contiene motor, asientos, bodega,
baos, ...
Nota: Si falta alguna de sus partes se afecta el
todo (las partes viven el el todo)
108
Taxonoma y generalizacin
Taxonoma (del griego taxis,
ordenacin + nomos, ley)
1 Disciplina que estudia los
principios, mtodos y fines de
clasificacin
Cuenta
2 Clasificacin de cualquier cosa

segn unos mtodos establecidos
Cuenta
corriente
Una generalizacin es una

relacin taxonmica entre un
elemento ms general y uno ms
especfico
Cuenta de
inters
Cuenta de
depsito
109
Generalizacin y
especializacin
Generalizacin implica
generalizacin-especializacin de
la clase base a la clase derivada
Donde existe una clase general y
diferentes clases especializacin
Empleado
es un
hereda de
Director
Conductor
La clase general se llama
Administrativo de camiones
superclase y las clases
especializacin se llaman subclases
Una generalizacin es una

relacin es un, es un tipo de,
hereda de
110
Generalizacin y herencia
La generalizacin cuando se manifiesta en
un lenguaje de programacin se le conoce
como herencia
La herencia es una relacin entre diferentes
clases, las cuales comparten caractersticas
comunes
111
Herencia: Definicin
Es un mecanismo para compartir atributos
operaciones
comunes
entre
clases,
mediante una relacin jerrquica y
transitiva, donde una clase hereda de otra
sus atributos y operaciones y aade otros
nuevos que van a ser exclusivos para ella y
sus posibles descendientes, o sea clases que
se formen de ella a su vez.
112
Herencia: Definicin
Es el mecanismo por el cual elementos ms
especficos incorporan estructura y
comportamiento definidos por elementos
ms generales.
UML
113
Herencia: Ejemplo
114
Herencia: Ejemplo
Clase: Acadmico
Atributos
Direccin
Edad
Nombre
Estudiante
Atributos
Sexo
Aos de estudio
Programa acadmico
Operaciones
Solicitar libros
Realizar reportes
Hacer abstracciones
Desarrollar investigaciones
Profesor
Operaciones
Asistir a clases
Entregar tareas
Hacer tesis
Atributos
Sexo
Especialidad
Grado acadmico
Operaciones
Impartir clase
Generar notas de clase
Asignar calificaciones
Comparticin de atributos y operaciones:

un objeto es la instancia de una clase
115
Generalizacin y herencia
Una superclase hereda a una subclase y una
subclase es heredada por una superclase
Se heredan los atributos, las operaciones y todas
las asociaciones
116
Generalizacin, herencia y
clases abstractas
Clase abstracta
es aquella que no tiene ningn objeto; i.e., no se
pueden crear instancias u objetos
Slo se utiliza para heredar de ella y para describir

atributos y comportamientos comunes de otras clases
Vehculo
(clase abstracta)
Automvil
Automvil
deportivo
Automvil
familiar
Avin
Automvil
turismo
Avin
militar
Avin de
carga
Avin de
pasajeros
117
Generalizacin, herencia y
clases concretas
Clases concretas
Son opuestas de las clases abstractas
Es posible crear instancias u objetos de ellas y
tienen implementaciones de todas las operaciones
Vehculo
(clase abstracta)
Automvil
Automvil
deportivo
Automvil
A
Avin
Automvil
familiar
Automvil
turismo
Automvil
B
Automvil
C
Avin
militar
Avin de
carga
Avin de
pasajeros
Instancias u objetos
118
Propiedades de la herencia
Permite reutilizacin
Los componentes pueden reutilizarse
Enfoque de reutilizacin bottom-up
Los diseos pueden reutilizarse

Enfoque de reutilizacin top-down
Permite claridad en la descripcin

Debido a que la descripcin de objetos en
trminos jerrquicos es una forma fcil y
comprensiva de comunicar tanto estructura
como funcionalidad
119
Herencia: Ejemplo
120
Polimorfismo
Una misma operacin puede tener
comportamientos diferentes segn el objeto que la
ejecuta.
Es decir, el mismo mensaje puede tener respuestas
diferentes por parte de objetos diferentes.
Sin embargo el sentido de la operacin sigue siendo

el mismo para las dos clases.
Luego en este sentido los objetos de ambas clases se
dicen polimrficos entre s.
Ejemplo
CalculaArea(int lado)
CalculaArea(int largo, int ancho)
121
Polimorfismo
El comportamiento del sistema se define por el
comportamiento dinmico de las instancias de
las clases
Segn Jacobson
Polimorfismo significa que el originador del mensaje
no necesita conocer a la instancia de la clase que lo
recibe. La instancia receptora puede pertenecer a
una clase arbitraria
122
Polimorfismo
El polimorfismo permite que diferentes instancias
de diferentes clases estn asociadas
Una instancia receptora interpreta las operaciones
de acuerdo a la clase a la que pertenece
Ejemplo:
El mensaje dibujar se puede interpretar de diferentes
formas por las instancias de una clase
123
Polimorfismo:
Formas de Aplicacin
Se detecta a travs de la firma de los mtodos
Nombre
Nmero de Argumentos
Tipo de Dato de los Argumentos

[Valor de Regreso]
Dentro de la misma clase

Sobrecarga de mtodos (funciones)
Caso Especial: Sobrecarga de Operadores
Entre clases de la misma jerarqua

Uso principal del Polimorfismo
124
Principio de Subclasificacin
Liskov
Este principio establece que toda clase B

descendiente de una clase A, no importa a que
nivel, puede verse haciendo abstraccin como una
clase A. O sea, los objetos de la clase B, son
tambin objetos de la clase A, pero no a la inversa.
Luego cualquier operacin que espere un objeto de
la clase A, puede recibir un objeto de la clase B, en
tanto los objetos de la clase B saben hacer todas
las operaciones que hacen los de la clase A.
125
Principio de Abierto/Cerrado
Reusabilidad y Extensibilidad
La mxima utilidad del polimorfismo es la

redefinicin de operaciones de las clases bases en
las clases derivadas.
Cerrado = el software ya elaborado no sufrir
modificaciones directas
Reusabilidad
Abierto = se puede definir nuevo software como

especializacin del anterior
Extensibilidad
Aplicacin de la Herencia
126
Implicaciones
La aplicacin ms importante de la herencia es
la simplificacin conceptual del problema al reducir el
nmero de caractersticas independientes, y
mecanismo para formar complejas estructuras de datos
por niveles de construccin desde ms abstractos hasta
ms concretos.
El que una clase comparta atributos y operaciones

de otra significa tener en cuenta consideraciones
como
el encapsulamiento y
el mantenimiento de la consistencia de la clase en las
clases derivadas.
127
Problema de Herencia Selectiva

Anulacin de operaciones de la clase base para la clase
derivada.
Aunque un buen diseo de clases exige que se mantenga el
principio de subclasificacin, o sea, todo lo que tenga sentido
para una clase base debe tenerlo tambin para sus
descendientes, en ocasiones se presentan problemas reales
donde se precisa de una herencia selectiva o herencia con
restricciones.
En el primer caso se heredar slo parte del comportamiento
de la clase base, que tenga sentido para la nueva clase, es
decir slo una parte de las operaciones. En el segundo, se
heredarn todas las operaciones pero algunas de ellas
tendrn redefiniciones con restricciones respecto a la forma
de sus parmetros.
128
Ejemplo
Aves
Color del plumaje
Perodo de incubacin
Anidar()
Aparearse()
comer()
Volar()
Pingino
Herencia con Anulacin

Volar()
129
Ejemplo
Rectngulo
Ancho
Largo
Cuadrado
Herencia con Restricciones

Crear( a,l )
Trasladarse()
Mostrarse()
Ocultarse()
Rel_Aspecto( a,l )
Crear( a,a )
Rel_Aspecto( a,a
)
130
Herencia: Consistencia
La herencia un mecanismo controlado de
redefinicin.
En ocasiones tambin es necesario contar con
herramientas (algunos lenguajes las tienen) para
lograr herencias que controlen la redefinicin no
slo en interfaz sino tambin en implementacin.
la clase base se puede adjudicar el derecho de
permitir la redefinicin de sus operaciones
imponiendo ciertas condiciones a la nueva
implementacin que mantengan la consistencia de
la clase. Por ejemplo, que despus de la operacin
se mantenga una cierta relacin entre los valores
de los atributos.
131
Herencia Simple
La clase se define o deriva a partir de una
nica clase base
Animal
Mamfero
Hombre
132
Herencia mltiple
Es una forma de herencia
en donde una clase
hereda la estructura y
comportamiento de dos
Director
clase base
Administrativo
Existen varias superclases

para una subclase
Permite estructuras de
clase ms complejas, pero
es menos fcil de
comprender
Empleado
es un
Empleado
eventual
Conductor
de camiones
es un
Empleado
de bodega
Empleado
de oficina
Todologo
133
Ambigedades en la herencia
mltiple
Colisin de nombres
Herencia incorrecta
repetida
A
(A)
(A)
(A)
(A)
?
?
134
Persistencia
Un objeto en software ocupa alguna cantidad de
espacio y existe para una cantidad particular de
tiempo. Existe un espectro de existencia de objetos
que va desde objetos transitorios que aparecen dentro
de la evaluacin de una expresin, hasta objetos en
una base de datos que sobreviven a la ejecucin de un
programa. [Atkinson]
Este espectro de persistencia de objetos abarca, entre
otras, las siguientes:
Resultados transientes en la evaluacin de una expresin
Variables locales en activaciones de procedimientos
Variables propias [como en Algol 60] y variables globales
Datos que existen entre las ejecuciones de un programa

Datos que existen entre varias versiones de un programa
Datos que sobreviven al programa
135
Persistencia
Los lenguajes tradicionales de programacin
usualmente direccionan solo los tres
primeros tipos de objetos persistentes, la
persistencia de los ltimos tres tipos es
tpicamente del dominio de la tecnologa de
bases de datos.
La persistencia es la propiedad de un objeto
a travs de la cual su existencia trasciende en
el tiempo (el objeto contina existiendo
despus de que su creador deja de existir)
y/o en el espacio (la localizacin del objeto
se mueve de la direccin en la cual ste fue
creado). [Booch]
136
Conclusiones: Caractersticas
de la OO
Reduce la brecha semntica entre la realidad
y los modelos
Hace que el sistema sea ms fcil de entender

Permite modificaciones locales de los modelos
Permite el manejo del cambio
Promueve la reutilizacin
Asegura la continuidad de la representacin
137
Conclusiones: Debilidades de
la OO
Reutilizacin a gran escala an no se
lleva a cabo
Existen pocas bibliotecas reutilizables
La administracin de las bibliotecas
reutilizables es un problema debido a
su falta de estandarizacin
Se requiere un entrenamiento fuerte
del personal antes de que se pueda
implantar
138
Conclusiones: La OO y los
sistemas
Los sistemas pueden ser
Basados en objetos
encapsulamiento + identidad de objetos
Basados en clases
basados en objetos + abstraccin de conjunto
Orientados a objetos
basados en clases + herencia +autorrecursin
139
INTRODUCCIN A UML
Y AL ADOO
Alejandro Domnguez
140
Panormica general
Surgimiento y desarrollo de
UML
UML como lenguaje de

modelado
Bloques que componen a UML
La arquitectura de los sistemas
Los modelos en UML

141
Surgimiento de UML
UML (Unified Modeling Language:
lenguaje unificado de modelado)
Es el sucesor de los diferentes
modelos para llevar a cabo anlisis y
diseo orientados a objetos (ADOO)
Naci como una unificacin de los
modelos de Booch, Rumbaugh
(OMT) y Jacobson (The 3 amigos)
Es el lenguaje de modelado estndar
aprobado por la OMG en 1997
142
Desarrollo de UML
OOSA
Shalaer/Mellor
Ada/Booch
Booch 91
Booch
1990
OOSE
Jacobsen
RDD
Wirfs-Brock
OMT
Rumbaugh et al.
OBA
Gibson/Goldb.
OOA
Coad/Yourdon
Booch 93
OOSE 94
1995
OMT 94
Fusion
Coleman
OODA
Martin/Odell
Harel
Cartas de
estado
UM 0.8
OOPSLA 95
Booch/Rumbaugh
SOMA
Graham
UML 0.9
MOSES
Henderson-Sellers
The 3 amigos
1997
UML 1.0
Team Fusion
The 3 amigos Notacin Coleman et al.
UML 1.1
Aceptado por
la OMG 11/97
OPEN/OML
Open-Group
(+30 colaboradores)
RD
Shalaer/Mellor
143
UML como lenguaje de

modelado
UML no es un mtodo
Un mtodo consiste en un lenguaje y en un proceso
para modelar
UML es un lenguaje de modelado
Un lenguaje provee un vocabulario y reglas para combinar
las palabras en ese vocabulario
El modelado conduce a un entendimiento de los sistemas
Un lenguaje de modelado es aquel cuyo vocabulario y
reglas estn enfocadas a la representacin conceptual y
fsica de un sistema
144
Caractersticas de UML
UML es un lenguaje para
Visualizar
Es un lenguaje grfico con una semntica bien definida
Especificar
Permite construir modelos precisos, no ambiguos, y
completos
Construir
UML no es un lenguaje de programacin visual, pero
los modelos creados con l pueden conectarse
directamente a una gran variedad de stos
Documentar
Permite expresar, a cualquier nivel de detalle, la
arquitectura, los requerimientos, y las pruebas de un
sistema
145
UML y los artefactos del

sistema
UML permite modelar los
artefactos inherentes de un
sistema
requerimientos, arquitectura,
diseo, cdigo fuente, planos del
proyecto, pruebas, prototipos,
versiones, etc.
Dependiendo de la cultura de
desarrollo estos artefactos se
tratan a un nivel de detalle
diferente
146
Bloques que componen a UML

El vocabulario de UML est compuesto por
tres grandes bloques
Cosas
Abstracciones en un modelo
Relaciones
Unen o ligan las cosas
Diagramas
Agrupan las colecciones de cosas
147
El bloque de las cosas en UML

Existen 4 tipos de cosas en UML:
Estructurales
Son los sustantivos o nombres de los modelos de UML
Casos de uso, clases, interfaces, componentes, nodos
De comportamiento
Son la parte dinmica de los modelos de UML
Interaccin entre objetos (mensajes y secuencias de
accin) y mquinas de estado
De agrupamiento
Son las partes organizacionales en los modelos de UML
Paquetes (mecanismos de propsito general para
organizar elementos en grupos)
De notacin
Son las partes que explican los modelos en UML
Notas
148
El bloque de las relaciones en

UML
Existen 4 tipos de relaciones en UML:
Dependencia
Es una relacin semntica entre dos cosas en la cual un
cambio de una cosa afectar la semntica de otra
Asociacin
Es una relacin estructural que describe un conjunto de
ligas (conexiones entre objetos)
Generalizacin
Es una relacin de especializacin/generalizacin en la
cual los elementos hijo se sustituyen por elementos padre
Realizacin
Es una relacin semntica entre clasificadores (especifica
un contrato que otro clasificador asegura llevar a cabo)
149
El bloque de los diagramas en

UML
Un diagrama es la representacin grfica de

un conjunto de elementos
UML comprende 8 diagramas:
Diagramas de casos de uso
Diagramas de clases y objetos
Diagramas de colaboracin
Diagramas de estado
Diagramas de actividad
Diagramas de componentes
Diagramas de implantacin
150
Arquitectura de los sistemas

(1)
La arquitectura de un
sistema se refiere a
Su organizacin
La seleccin de los elementos
estructurales, y sus interfaces
que lo componen
Su comportamiento
expresado como colaboraciones
entre sus elementos (o
subsistemas)
151
Arquitectura de los sistemas

(2)
La arquitectura de un
sistema se refiere a (cont.)
La conjuncin de estos
elementos estructurales y de
comportamiento en sistemas
mas grandes
El estilo arquitectnico que
gua esta organizacin
los elementos estticos y
dinmicos y sus interfaces, sus
colaboraciones, y su
composicin
152
Modelo de una arquitectura

de sistemas
CASOS DE
USO DEL
SISTEMA
PRUEBA
153
La arquitectura como constructora

de modelos
Modelo de
requerimientos
Modelo de
anlisis
Modelo de
diseo
CASOS DE
USO DEL
SISTEMA
Modelo de
implementacin
PRUEBA
Modelo de prueba
154
Los modelos y la representacin

en UML: alcance del curso
Modelo de
requerimientos
Modelo de casos de uso
Diagrama de clases
(primera versin)
Modelo de
anlisis
Diagrama de clases
(+ paquetes)
Asociaciones
Atributos
de Clases
Modelo
diseo
Clases
Casos de uso
Casos de uso
(+ descripciones)
Secuencia de las
operaciones
Diagrama de secuencias
Estados de las
Diagrama de estado operaciones
Definicin de la interfaz 2 Definicin
Diagrama
de la 155
de clases
interfaz 1
MODELO DE
REQUERIMIENTOS
(MODELADO DE CASOS
DE USO )
Alejandro Domnguez
156
Panormica general
Proporcionar las bases del
modelo de casos de uso (use
cases):
Actores
Casos de uso
Notaciones relevantes de UML
157
Entorno del modelo de casos

de uso
Modelo de
requerimientos
Modelo de
anlisis
Diagrama de clases
(primera versin)
Diagrama de clases
(+ paquetes)
Asociaciones
Atributos
de Clases
Modelo
diseo
Clases
Casos de uso
Casos de uso
(+ descripciones)
Secuencia de las
operaciones
Diagrama de secuencias
Estados de las
Definicin de la interfaz 2 Definicin
Diagrama
de la 158
de clases
interfaz 1
Caractersticas de los
requerimientos de un sistema
Los requerimientos de un
sistema
Necesitan ser los adecuados
Necesitan estar ms enfocados al

usuario
Son los primeros en someterse a
un proceso de reingeniera
Deben involucrar 100% al usuario
Los requerimientos de un
sistema deben centrarse en los
usuarios
159
Anlisis centrado en los

usuarios
En un proceso para capturar los
requerimientos desde la
perspectiva de los usuarios
Tell me what you want,

what you really, really want
Seguido de
Anlisis
Explora la conectividad y las consecuencias
de los conflictos (diferentes y potenciales)
que surgen en los requerimientos del
usuario
Diseo
Mapea los requerimientos en una
aplicacin de software
160
Obtencin de los
requerimientos del usuario
El usuario debe decir
que desea
Observar y tomar nota

de cmo el usuario
trabaja
El analista debe
Estructurar la
informacin de tal forma
que pueda ser utilizada
ms tarde en el anlisis
y diseo
Entender el negocio del

usuario
Conocer las
caractersticas de todas
las cosas y personas
que interactuarn con el
sistema
Tomar tiempo para
explorar las necesidades
del usuario
Descubrir, con ayuda de

expertos, las reglas de
negocio crticas
Enfocarse en el qu y
no en el cmo
161
Durante y despus de
los requerimientos
El analista debe
Escribir la informacin recolectada de tal forma
que el usuario la comprenda
Crear una serie de diagramas acerca del negocio
del usuario
Ayudan a la comprensin
Proporcionan un punto de partida para confirmar los
requerimientos reales
Los modelos de casos de uso ayudan llevar

a cabo lo anterior
162
Qu es un modelo de casos
de uso?
Un modelo de caso de uso:
Describe los servicios que el
sistema proporciona al usuario
Proporciona informacin acerca
de los usuarios (actores) del
sistema
Actores: Humanos, otros sistemas,
mquinas
Muestra la naturaleza de las

interacciones entre el actor y el
sistema (casos de uso)
El sistema contiene los casos de uso
Relaciona actores y casos de uso
163
Produccin de un modelo de
casos de uso
INPUTS
PROCESOS
Prcticas
existentes de
sistemas
Requerimientos
del nuevo
sistema
Derivar posibles actores y

casos de uso
Discriminar sobre posibles
caso de uso
Identificar asociaciones
entre casos de uso
OUTPUTS
1 modelo de
casos de uso
164
Actores
Un actor
Es alguien o algo externo al sistema
Personas, software, hardware, almacenes de datos, o redes
No sigue acciones precisas

Representa cualquier cosa fuera del sistema y que
interactuar con l
Puede ser humano o un mquina
Los detalles acerca de los actores son no

necesarios
SISTEMA
Cliente
Operador
165
Quines pueden ser actores?

Los usuarios del sistema
Los instaladores del sistema
Los operadores del sistema

Los que dan soporte tcnico al sistema
Otras sistemas que utilizan el sistema
Los que obtienen informacin del sistema
Los que proporcionan informacin al sistema
166
Actores primarios
Son aquellos para los cuales se
especifica y se construye
Son activos
Inician su actividad con el sistema
Usuario de computadoras con la
computadora
Usuario del telfono con el telfono
Cobrador con el sistema de cobranza
Interanuta con el visualizador web
Obtienen siempre algo a cambio
167
Actores secundarios
Supervisan, ayudan y mantienen al sistema
Son pasivos: no inician ninguna actividad con el
sistema
Slo existen para que los actores primarios

puedan utilizar el sistema
Siempre disponibles cuando el sistema necesita de
su ayuda
Pueden ser mquinas u otros sistemas

Impresoras, plotters, modems, ...
Aplicaciones adicionales
Posiblemente actores humanos
168
Caractersticas de los actores

Un actor no es un usuario en particular
Un actor representa el papel que juega el
usuario
Un usuario es alguien que juega un papel
especfico mientras usa el sistema
Juan Prez es un alumno
Cada actor utiliza el sistema de formas

diferentes
De otra forma debera ser el mismo actor
Cada forma en que el usuario utiliza el

sistema es un caso de uso
169
Casos de uso (1)

Describen las
transacciones ofrecidas
por el sistema
Son iniciados por los

actores
Pueden ser llamados
por otros casos de uso
Pueden ser
combinados para
ofrecer mayor
funcionalidad
Representan lo qu el
sistema debe
proporcionar, en lugar
de cmo lo debe hacer
Cmo el sistema
proporcionar el servicio
no debe ser importante
para el usuario
Cuando se utiliza el
telfono , no es
importante cmo se
lleva a cabo la
conexin con otro
170
Casos de uso (2)

Un caso de uso:
Es una serie completa de caminos de las
acciones (con eventos de inicio y trmino,
con actores involucrados y objetos
utilizados en la accin) y las reglas que
gobiernan cmo se ligan esas acciones
Es la definicin de la interaccin entre el

sistema y el actor
Incluye los caminos normales y
alternativos
Es parecido a un proceso de interaccin
humano-mquina
171
Casos de uso (3)

Los casos de uso existen debido a
las necesidades del usuario
De esta forma se garantiza que el
sistema har lo que el usuario espera
Los casos de uso no son escenarios

No son recolectores de un conjunto
particular de interacciones entre el
usuario y el sistema
Los casos de uso surgen a partir de
los escenarios
172
Casos de uso y escenarios (1)

Un escenario
Es un orden especfico de
eventos
Es una sesin que un actor

tiene con el sistema
Tiene detalles de los datos
reales y de la salida esperada
Puede ser ligeramente
diferente que el previo, an
cuando se haga
esencialmente lo mismo
173

Pueden existir cientos de
escenarios en un aplicacin
Los escenarios son importantes
fuentes de informacin para
descubrir casos de uso
Mas de un escenario se puede

generar de un simple caso de
uso si una o ms reglas para
ligar a las acciones no estn en
secuencia estricta
174

Los casos de uso proporcionan un conjunto
potencial de escenarios
Observando una familia de escenarios
similares, se puede obtener la esencia de lo
que se est llevando a cabo
Escenarios similares seguirn patrones similares
y proporcionarn tipos similares de resultados
Escenarios
Caso de uso
175

Ejemplo de escenario 1
Juan teclea la cuenta 12345
Juan teclea su NIP 54321
Juan su balance promedio entre 1/1/1995 - 31/12/99
El sistema proporciona el balance promedio
Mara teclea la cuenta 23457
Mara teclea su NIP 75432
Mara su balance promedio entre 1/1/1995 - 30/12/99
Pedro teclea la cuenta 23456
Pedro teclea su NIP 65432
Pedro su balance promedio entre30/11/1999 - 30/12/99
176

Existen dos tipos de escenarios
Primarios
Describen lo que sucede en un flujo normal de interaccin
con el sistema
Existen cuando
Todo funciona bien
No existen bugs
No existen errores
Secundarios
Describen las excepciones encontradas en un flujo normal
(flujos alternativos)
Existen cuando
Una accin debe tomarse en algn punto
Algo es errneo en algn punto
Algn comportamiento que puede pasar en algn momento
177
Descripcin de actores y
casos de uso
Cada actor necesita
un nombre descriptivo
una breve descripcin de una o dos oraciones
de longitud
Las sentencias deben describir al actor con respecto
al sistema
Cada caso de uso necesita

Un nombre descriptivo
Una descripcin de una o dos oraciones de

longitud
Slo si el nombre no dice suficiente acerca de la
funcionalidad del caso de uso
178
Ejemplos de descripcin de
actores
Actores
Cliente - una persona quien ordena
productos de la compaa
Vendedor - un empleado de la compaa
quien procesa los pedidos del cliente
Mensajera - UPS, FedEx, DHL, MexPost,
etc.
Empacador - Un empleado de la compaa

que empaca, etiqueta y enva ordenes
Sistema de inventario - software que
almacena y procesa la informacin del
inventario de productos
Sistema contable - software que almacena
y procesa la informacin contable
179
Prctica
Tabla de Actores
Nombre del
Actor
Tipo
Descripcin
Primario
Secundario
Ambos
180
Ejemplos de descripcin de
casos de uso
Casos de uso
Del cliente - elaborar orden, obtener estado de orden,
regresar producto, cancelar orden, registrar observaciones
Del vendedor - elaborar orden, obtener estado de orden,

regresar producto, cancelar orden, registrar observaciones
A la mensajera - enviar paquetes listos para envo
Del empacador - imprimir etiqueta de correo, calcular cuota

postal
Al inventario del sistema - proporcionar informacin del
producto, actualizar inventario
Del inventario del sistema - capturar las ordenes recibidas
Al sistema contable - cargar a cuenta, proporcionar crdito
181
Prctica
Relacin de Actores con Casos de Uso
Actor
Direccin Casos de Uso
182
El modelo de casos de uso y

la descripcin de sistemas (1)
El modelo de casos de uso caracteriza el
comportamiento de todo el sistema y los
actores externos
Un sistema se describe por un modelo de
casos de uso
El modelo contiene un conjunto finito de casos
de uso
183

Un sistema potencialmente tiene un
nmero infinito de escenarios
Familias de escenarios generan casos de uso y
stos a su vez el modelo de casos de uso
Cada caso de uso en el modelo debe ser

numerado, de otra forma el sistema no
ser funcionalmente completo
184

Con el modelo de casos de uso el
sistema puede ser puesto a prueba en
sus entradas (inputs), salidas (outputs) y
naturaleza de la interaccin
185
Notacin grfica en un
diagrama de casos de uso
Notacin para
un actor
Nombre
del actor
Notacin para
el sistema
Nombre
del sistema
Notacin para
el caso de uso
Nombre del
caso de uso
Nombre: frase verbal
activa o en infinitivo
186
Diagrama bsico de un caso

de uso
Nombre del sistema
Nombre del
caso de uso
Nombre
del actor
187
Actores primarios en un
Sistema de inversiones
Ejecutar orden
Actores
primarios
Corredor
de bolsa
Verificar inversin
Inversionista
188
Actores secundarios en un
Sistema de inversiones
Actores
primarios
Actor
secundario
Ejecutar orden
Corredor
de bolsa
Verificar inversin
Sistema
bancario
Transferir dinero
Inversionista
189
Reglas para crear diagramas

de casos de uso
Los actores primarios
se muestran a la
izquierda del diagrama
y los secundarios a la
derecha
Un caso de uso debe
proporcionar un
servicio real al usuario
Escribir los nombres de
los casos de uso dentro
de la elipse con el fin
de ahorrar espacio
Mantener los
diagramas claros y
ntidos
No poner demasiados
casos de uso en un
diagrama
Diagramas sencillos son
mas fciles de entender
190
Relaciones de generalizacin
en casos de uso
Estas relaciones estn ligadas a los escenarios
secundarios
Extend
Cuando un caso de uso se extiende a otro al agregar acciones
Include
Cuando un caso de uso incorpora el comportamiento de otro
caso de uso en un lugar especfico del primero
Verificar balance
Validar cuenta
<<include>>
Prestar efectivo
<<extend>>
Verificar cantidad prestada
191
Extensiones de casos de uso

(extend)
Las extensiones
Permiten al analista cambiar o
agregar funcionalidad un caso de
uso base, sin alterarlo
Un caso de uso es similar a otro, pero
este ltimo hace un poco ms
Se utilizan para modelar partes

opcionales de un caso de uso
Caminos alternativos complejos se
deben modelar en casos de uso
diferentes
192
Diagrama de la asociacin
extend
Sistema de cajero automtico

Verificar balance
<<extend>>
Capturar
transacciones
Prestar efectivo
Cliente
del banco
<<extend>>
<<extend>>
Depositar efectivo
193
Inclusin de casos de uso

(include)
La inclusin
Es diferente que la relacin de
extensin
Es ms una subrutina, ms que
una especializacin
Aparece cuando un cumulo de
acciones es recurrente en
muchos casos de usos y se
quiere evitar repetir la
descripcin de este cumulo
Cada cumulo de acciones deben
manejarse de forma separada en
otros casos de uso
194
Diagrama de la asociacin
include

Verificar balance
<<extend>>
Capturar
transacciones
<<extend>>
Prestar efectivo
Cliente
del banco
<<extend>>
Depositar efectivo
<<include>
<<include>
Generar anotacin
195
Herencia en casos de uso y

actores
Existe herencia entre casos de uso
En un caso de uso la herencia puede se
utilizada entre actores
Debido a que son considerados como clases
en UML
Herencia entre actores significa que un

actor cumple el mismo papel que otro
actor y puede jugar papeles adicionales
Cliente
hereda
Cliente
del banco
196
Propiedades de la herencia
entre actores
Simplifica el diagrama
sin perdida de detalle
Cliente
del banco
Seala la relacin
jerrquica entre actores
El actor receptor obtiene
las capacidades del actor
padre
Los actores padres no
notan la presencia de la
herencia
Persona
fsica
Persona
moral
Otro
banco
197
Diagrama de la herencia entre

actores
Verificar balance
<<extend>>
Capturar
transacciones
Cliente
del banco
Prestar efectivo
<<extend>>
<<extend>>
Depositar efectivo
Obtener comisin
Otro
banco
198
Consejos para el modelado de

casos de uso (1)
Considerar la situacin en la
que se utiliza el sistema
Definir las fronteras del sistema

Identificar todos los actores
Identificar todas las tareas para
las cuales el sistema se utiliza
Identifique todos los caminos

alternativos
199
Consejos para el modelado de

casos de uso (2)
Revisar constantemente todos
el modelo de caso de uso
Distinguir los diferentes casos

de uso utilizando frecuencias de
uso
Describir nicamente las
acciones en las que interviene
una interaccin entre el actor y
el sistema
200
Ejemplo: el problema
Definir el modelo de casos de uso
para un sistema de biblioteca:
Mostrar las relaciones include y extend
entre los casos de uso y los casos de
uso abstractos
Incluir al menos 3 casos de uso:
Caso de uso para la bsqueda de libros
Caso de uso para el prstamo de libros
Caso de uso para el regreso de libros
Definir los caminos normales y

alternativos de los casos de uso
201
Ejemplo: descripcin de
actores y casos de uso
Actores
Usuario - persona que interacta directamente
con el sistema
Bibliotecario - persona que da soporte al sistema

y auxilia al usuario en los servicios de prstamo
Casos de uso
Del usuario - buscar por autor, buscar por ttulo,
buscar por clave, buscar por autor-ttulo,
reservar libro
Del bibliotecario - prestar libro
Al bibliotecario - regresar libro
202
Ejemplo: el modelo a documentar

Reservar
libro
<<include>>
<<extend>>
Autenticar usuario
Regresar
libro
Buscar libro
Usuario
<<extend>>
<<extend>>
Buscar por autor

<< include >><<extend>>
Buscar por ttulo

<< include >>
<<extend>>
Buscar por clave
Bibliotecario
<<include>>
Buscar por autor-ttulo

<<include>>
Accesar datos de
libros actuales
<<extend>>
Buscar libros
actuales
Prestar
libro
203
MODELO DE ANLISIS
(DIAGRAMAS DE CLASE)
Alejandro Domnguez
204
Panormica general
Desarrollar las descripciones de
casos de uso
Describir los principios de los
diagramas de clase
Construccin de diagramas de clase
a partir del modelo de casos de uso
Introducir nuevos tipos de objetos
Determinar los principios para el

diseo por etapas
205
El modelo de anlisis
Modelo de
requerimientos
Diagrama de clases
(primera versin)
Modelo de
anlisis
Diagrama de clases
(+ paquetes)
Casos de uso
(+ descripciones)
Secuencia de las
operaciones
Diagrama de secuencia
Estados de las
DIAGRAMA Definicin de la interfaz 2 Definicin
de la206
DE CLASES
interfaz 1
Asociaciones
Atributos
Modelo de Clases
diseo
Clases
Casos de uso
Produccin de un modelo de
descripcin de casos de uso
INPUTS
Diagramas de
casos de uso
PROCESOS
OUTPUTS
Generar descripciones de
casos de uso
Refinar y completar casos
de uso y el modelo
Describir y probar
interfaces de usuario
Describir interfaces del
sistema
1 modelo de
casos de uso
Descripciones
del caso de
uso
Descripciones
de la interfaz
del usuario
207
Descripciones de casos de
uso
A cada elipse se debe
asociar un texto que
describa el caso de uso en
mas detalle
El texto puede ser resmenes
con palabras clave
Cada elipse puede incluir

condicionales,
ramificaciones, y ciclos
The rational unified process
tiene un formato bsico para
describir los casos de uso
Formato bsico
Nombre
Actores
Pre-condiciones
Flujo de eventos
Post-condiciones
Caminos alternativos
208
Elementos del formato bsico

de descripcin (1)
Actores
Actores relacionados con el caso de uso
Pre-condiciones
Estado del sistema antes que el caso de
uso ocurra
Post-condiciones
Estado del sistema despus de que el
caso de uso ha ocurrido exitosamente
209

de descripcin (2)
Flujo de eventos
Serie de declaraciones que
listan los pasos de un caso
de uso
Son el ncleo principal del
caso de uso
Asociados a los escenarios
primarios
Alternativas y repeticiones
se muestran utilizando
ramificaciones o listandolos
en la seccin de caminos
alternativos
Se utilizan las sentencias

Si ... Entonces ... para
indicar alternativas
Repetir ... hasta que ...
cuando se necesita repetir
un paso o un conjunto de
pasos al menos una vez
Mientras que ... cuando se
necesita repetir un paso o
un conjunto de pasos al
cero ms veces
Para (#inicial) hasta
(#final) hacer ... Cuando se
necesita repetir un paso o
un conjunto de pasos un
nmero definido de veces
210

de descripcin (3)
Alternativas al camino principal
Se utilizan en lugar de una ramificacin cuando
la alternativa es compleja
Apropiados para mostrar cosas que pueden
pasar en cualquier momento
Algo que puede interrumpir el flujo normal de eventos
Excepciones y situaciones de error que pueden

ocurrir en el contexto del caso de uso
No son errores tcnico, sino errores relativos al
dominio
Prdida de derechos de acceso, imposibilidad de
llenados de formas, etc.
211
Ejemplo: el modelo a describir

Reservar
libro
<<extend>>
<<extend>>
Autenticar usuario
Regresar
libro
Buscar libro
Usuario
<<extend>>
<<extend>>
Buscar por autor

<< include >><<extend>>
Buscar por ttulo

<< include >>
<<extend>>
Buscar por clave
Bibliotecario
<<include>>
Buscar por autor-ttulo

<<include>>
Accesar datos de
libros actuales
<<extend>>
Buscar libros
actuales
Prestar
libro
212
Ejemplo: Descripcin de
buscar por ttulo
Actores: Usuario
Pre-condiciones: El sistema est en espera de

datos de bsqueda
Flujo de eventos:
1. El usuario teclea las palabras clave y entonces
presiona el botn de bsqueda
2. El sistema despliega los datos del libro que tiene
todas las palabras clave que aparecen en el ttulo
2.1. do include accesar datos de libros actuales
3. Si el libro existe, entonces do extend buscar libro
Post-condicin: El sistema est en posibilidades

de reservar el libro
213
reservar libro (1)
Actores: Usuario
Pre-condiciones: El sistema est en
posibilidades de reservar libro
Flujo de eventos:
1. Si el sistema no tiene informacin para autenticar
al usuario, entonces do extend autenticar usuario
2. Si el usuario conoce datos del libro y desea
reservarlo, entonces introduce datos al sistema y
presiona el botn reservar, de otra forma el sistema
le informa que el libro no est disponible
214
reservar libro (2)
4. Si el usuario quiere salir, entonces presiona el
botn SALIDA
5. Si el usuario no conoce datos del libro y desea
reservarlo, entonces ir casos de uso de bsqueda
Post-condiciones: El sistema hace reservacin
215
Interfaces
Pueden ser definidas por
actores, casos de uso, o ambos
Dice lo que se espera que la
entidad haga
No es parte de los actores o
casos de uso
Es una descripcin de cmo
interactuar con el actor o caso de
uso
Puede existir ms de una

interfaz para un actor o caso de
uso
216
Estructura de las interfaces

Una interfaz tiene un nombre y un conjunto de
firmas de operaciones (operation signatures)
Una firma de operacin seala el tipo de dato que se
pasa con operacin y el tipo de dato que se pasa
cuando la operacin se completa
La operacin seala que se espera que la entidad haga
Ejemplo: Interfaces para el caso de uso buscar por ttulo

Buscar por ttulo ( )
Introducir palabras clave (Palabras Clave)
Regresar ttulos con palabras clave
Presionar buscar libro( )
217
Notacin para interfaces

Interfaz
del usuario
Efectuar pedido
Cliente
Indican quin
usa la interfaz
Interfaz para
bsqueda
de pedidos
Interfaz
para ordenar
pedidos
Cancelar pedido
Vendedor
218
Pantallas para interfaces

Dada la definicin de las
interfaces se disean las
respectivas pantallas
Omitir pantallas de error y
de informacin
No invertir demasiado
tiempo en la apariencia
TTULO
CAMPO 1
CAMPO 2
CAMPO 3
OK
Cancelar
219
Mapa de navegacin de
interfaces (1)
Una vez diseadas las
interfaces se debe
hacer un mapa de
navegacin entre ellas
El mapa de navegacin
seala la secuencia de
la interaccin humanomquina va las
interfaces de usuario
Notacin
Rectngulo = pantalla
Seala que otra pantalla ser
invocada
Circulo = pantalla hoja

Seala que ninguna otra
pantalla ser invocada
Cada rectngulo y circulo

contienen ttulo y el nmero o
nombre del caso de uso
Flecha unidireccional = flujo
entre interfaces
Flecha bidireccional = cancelar
220
y regresar
Mapa de navegacin de
interfaces (2)
TTULO
CAMPO 1
Login
UC001
Pantalla
Principal
UC002
CAMPO 2
CAMPO 3
OK
Cancelar
Despliegue
de Horario
UC003
Despliegue
de Materias
UC004
Confirmacin
221
Recomendacin para las

interfaces
Definir un nmero considerable de
pequeas interfaces
Esto hace el sistema ms flexible para
cambios futuros debido a que
Una interfaz completa se puede agregar
o remover fcilmente, ms que cambiar
una existente
Se puede utilizar una misma interfaz con
un actor o caso de uso
Se pueden reutilizar
222
Documentacin final del sistema

por casos de uso (template)
1. Nombre del sistema
2. Breve descripcin del sistema
3. Actores y casos de uso
4. Casos de uso
4.x. Nombre del Caso de Uso
Actores
Pre-condiciones
Flujo de eventos
Post-condiciones
Interfaces
5. Diagrama de casos de uso
6. Diagrama de secuencias de interfaces
223
El modelo final de casos de

uso
FASES DE
PRODUCCIN
224
El modelo final de casos de

uso (continuacin)
FASES DE
PRODUCCIN
225
Produccin de un diagrama
de clases
Propsito: Proporcionar un modelo lgico del software del sistema
OUTPUTS
PROCESOS
INPUTS
Modelo de
casos de uso y
descripciones
Listado de
objetos en el
dominio del
problema
Bosquejar el diagrama de
clases inicial
Reexaminar el
comportamiento de en los
casos de uso y los objetos
Refinar el diagrama de clases
Efectuar verificaciones de los
diagramas
Revisar diagramas de clase
Agrupar clases en paquetes
Diagramas de
clase
incluyendo
descripciones
de las clases
Asociaciones
entre clases
El papel que
juegan las
clases
Jerarquas de
herencia
226
Descripcin de objetos
atributos y operaciones
En las descripciones de los casos de
uso
Los objetos y las clases se determinan
subrayando cada sujeto o sustantivo
Los atributos se determinan subrayando
todos los adjetivos asociados a sus
respectivos objetos
Las operaciones se determinan
subrayando todos los verbos y frases
verbales asociados a los respectivos
objetos
227
Clases en UML
Existen dos notaciones posibles:
Nombre de la clase
Nombre del atributo: tipo
Operacin (parmetro: tipo): tipo de resultado
Nombre de la clase
Polgono
centro: punto
vrtices: lista de puntos
color del borde: color
color de relleno: color
despliegue (on: superficie)
rotar (ngulo: entero)
borrar ( )
destruir ( )
seleccionar (p: punto): boolean)
Polgono
228
Objetos en en UML
Existen dos notaciones posibles:
Nombre del objeto
Nombre del atributo: tipo
Triangulo1: Polgono
centro = (0,0)
vrtices = (0,0), (4,0), (4,3)
color del borde: negro
color de relleno: blanco
(mismas operaciones para todas

las instancias de una clase)
despliegue (on: superficie)

rotar (ngulo: entero)
borrar ( )
destruir ( )
seleccionar (p: punto): boolean)
Nombre del objeto: Nombre de la clase
Triangulo1: Polgono
229
Generalizacin en UML
Superclase
Personal
Bibliotecario
Subclase
Instructor
Subclase
Investigador
Subclase
Manejador
Manejador
de teclado
Manejador
de mouse
Manejador
de joystick
230
Asociaciones en UML (1)

asociacin
navegacin (permite comunicacin
por medio del envo de mensajes)
todo
todo
partes
composicin (todo contiene partes)

ventana contiene men, botn, ...
(el todo posee a sus partes)
(las partes viven en el todo)
partes
agregacin (todo tiene partes)

la universidad tiene facultades
(las partes componen el todo)
231
Asociaciones en UML (2)

ciudad
nombre
poblacin
es capital de
Asociacin simple
pas
nombre
poblacin
Joven
nombre
/es yerno de
Asociacin derivada
Joven
nombre
es novio de
Joven
nombre
232
Asociaciones (3)
empresa
persona
trabaja para
nombre
nombre
empleado #IMSS
domicilio empleador
Roles
Muchos
Exactamente uno
Cero o ms
0..
Uno o ms
1..
Cero o uno
0..1
Rango especificado
2..4, 7
233
Ejemplos de asociaciones en
UML
Usuario
autorizar en >
Estacin
de trabajo
1
Notacin para
clase asociada
Autorizacin
prioridades
privilegios
iniciar sesin
terminar sesin
Atributo
Nombre
atributos
operaciones
Operacin
Directorio
234
Estereotipos
Se utilizan para especificar la semntica de
elementos ya definidos en UML
Son elementos generalizables (se pueden
especializar o generalizar)
Se pueden especificar en una clase delante del
nombre de la clase
Indican que tipo de clase es y se indica como

<< >>
Se sitan encima o delante del nombre del
elemento
<<Actor>> <<nico>>
<<GUI>>
Cliente
Gerente
Ventana
235
3 estereotipos importantes
Clases interfaz
Para todo lo relacionado las interfaces del
sistema
Clases entidad
Para informacin persistente y el
comportamiento acoplado a ella
Clases control
Para funcionalidad no necesariamente atada a
otras clases
236
Estereotipos: Clases interfaz

Contienen la funcionalidad directamente
dependiente del entorno del sistema
Se centran en la interaccin entre los
actores y los casos de uso
<<interface>>
Impresor
de recibo
imprimir (recibo)
<<interface>>
Dispositivo
de alarma
sonido (alarma)
237
Estereotipos: Clases entidad y

sus atributos
Almacenan informacin que persiste
despus de completar un caso de uso
Definen el comportamiento para
manipular esta informacin
<<entidad>>
Depositar
artculo
Nombre: cadena
valor depositado: ECU
Total diario: entero
Las operaciones se caracterizan por:
Crear ()
Obtener_valor (entero)
Incremento ()
almacenar y obtener informacin
crear y remover objetos

el comportamiento cambiante si el objeto
entidad cambia
<<entidad>>
Lata
<<entidad>>
Botella
<<entidad>>
Caja
238
Estereotipos: Clases control

Son necesarias para:
Definir el comportamiento no natural en las
clases interface y entidad
Fungir como goma de pegar entre clases en
casos de uso
Definir comportamientos tpicos de control
Mejorar el mantenimiento del sistema
<<control>>
Controlador
Verificar_validez ()
Calcular_total ()
Mandar_a_imprimir ()
<<control>>
Generador de reportes
Compilar (Reporte)
Monitorear (Reporte)
Imprimir (Reporte)
239
Explotacin de los casos de uso

para dibujar diagramas de clase
Emplear clases, casos de uso, descripciones de casos
de uso, listas de objetos, clases, atributos y
operaciones para
definir el primer bosquejo de las clases y los atributos
definir asociaciones entre clases

describir roles y responsabilidades de cada clase
distribuir el comportamiento especificado en los casos de uso
para cada clase
asegurar que existe una clase para cada comportamiento
revisar y refinar el diagrama
producir una vista del caso de uso, i.e., un diagrama de clases para
cada caso de uso
producir un nico diagrama de clases para todos los casos de uso240
241
Paquetes (1)
Son consecuencia del gran
nmero de clases existentes en
un sistema
Son necesarios para:
Proporcionar funcionalidad
opcional
Minimizar los efectos del cambio
Deben poseer
Acoplamiento interno fuerte
Acoplamiento externo dbil
242
Paquetes (2)
Pueden
Contener paquetes
anidados con paquetes de
servicio como partes
atmicas
Tener clases individuales
fuera de ellos
Ser el resultado de
problemas
organizacionales o
administrativos
243
Ejemplo de paquetes
<<subsystem>>
Editor
Controler
Diagram
elements
Domain
elements
Graphics
core
WindowsCore
MotifCore
Windowing
system
Motif
Microsoft
Windows244
Modelo de anlisis
ETAPAS DE PRODUCCIN
245
EL MODELO DE DISEO
(DIAGRAMAS DE
SECUENCIA)
Alejandro Domnguez
246
Panormica general
Definir la relacin entre el anlisis y
el diseo
Definir las fases de diseo

Sealar el impacto que tiene el
ambiente de implementacin
Definir los diagramas de secuencia
Crear clases interfaz

247
El modelo de diseo I
Modelo de
requerimientos

Diagrama de clases
(primera versin)
Modelo de
anlisis
Diagrama de clases
(+ paquetes)
Casos de uso
(+ descripciones)
Secuencia de las
operaciones
Estados de las
de la
DE CLASES
interfaz248
1
Asociaciones
Atributos
Modelo de Clases
diseo
Clases
Casos de uso
Contenido del modelo de

diseo
INPUTS
OUTPUTS
Especificacin
de
requerimientos
relacionados al
ambiente de
implementacin
Modelo de
anlisis y
diagramas de
clase
Descripciones
de los casos de
uso
Diagramas de
secuencia (un
diagrama por
caso de uso)
Diagramas de
estado (un
diagrama por
clase)
Modelo de
diseo
completo
(diagramas de
clase)
249
PROCESOS
Identificar el ambiente de
implementacin
Modelar el diseo inicial del
diagrama de clases
Disear el control de flujo
Definir la clase interfaz
Modelar diagramas de estados
Finalizar el diseo del
diagrama de clases
Diagramas de clase con UML

en anlisis y diseo
DIAGRAMAS DE CLASE
EN EL ANLISIS
Modelo conceptual del sistema
DIAGRAMAS DE CLASE
EN EL DISEO
Construccin del sistema
MISMA NOTACIN, DIFERENTE PERSPECTIVA
250
El ambiente de
implementacin
Factores que intervienen
Sistema operativo
Lenguaje de programacin
Sistema de administracin de la
interfaz de usuario
Administrados de bases de datos
ANLISIS
DISEO
AMBIENTE DE
IMPLEMENTACIN
Bibliotecas reutilizables
Procesos de desarrollo
251
Ejemplo: Cambios debido al

lenguaje de implementacin
Utilizacin de un lenguaje que no soporta
herencia mltiple (e.g. Java)
<<entidad>>
Empleado
<<entidad>>
Director
<<entidad>>
Empleado de
tiempo parcial
<<entidad>>
Empleado de
tiempo parcial
<<entidad>>
Secretaria
<<entidad>>
Secretaria
<<entidad>>
Secretaria de
tiempo parcial
<<entidad>> 1..1
Secretaria de
tiempo parcial 252
1..1
tiempo parcial
<<entidad>>
Empleado de
tiempo completo
<<entidad>>
Empleado
Etapas iniciales del diseo
?
?
?
Traduccin del modelo de
anlisis al modelo de diseo
Diseo del flujo

de control
Adaptacin al medio ambiente y revisar

253
De todas la tcnicas de modelado de UML,
esta es probablemente la ms compleja
Son tiles para decidir y modelar cmo el
sistema llevar a cabo lo que se describi
en el modelo de casos de uso
Ayudan a asignar responsabilidades a las
clases y objetos
Ayudan para que se pueda comprender en
un programa OO el flujo de control
(secuencia) general de los objetos
254
Receta para la creacin de un

diagrama de secuencia (1)
1. Tomar la descripcin un caso de uso
y convertirla en pseudocdigo
colocandola a la derecha del
diagrama
2. A partir de la descripcin del caso de
uso, seleccionar las clases que se
tomarn en consideracin
3. Para cada uno de los pasos en
pseudocdigo, decidir cuales clases
tienen la responsabilidad de hacer
qu tarea
255
Receta para la creacin de un

diagrama de secuencia (2)
4. Para cada una de las tareas, dividirlas
en tarea menores
5. Agregar lo correspondiente para los
include y extend del caso de uso
6. Considerar los posibles errores
importantes que no fueron cubiertos
por el modelo de casos de uso
7. Considerar los nuevos
descubrimientos de necesidades y
alimentarlos al modelo de casos de
uso
256
Diagrama de secuencias en
UML: La notacin
Muestra interacciones entre un
conjunto de objetos en forma
temporal
crear
B
f( )
C
crear
g( )
Objetos: Su existencia se muestra como

una lnea vertical (lnea de vida)
tiempo
Convenciones de notacin:
h( )
Mensajes: Lneas horizontales

etiquetadas con el nombre del mensaje y
sus valores del argumento
Tiempo de activacin del objeto:
Rectngulos delgados
Destruccin de objetos: Denotado por X
destruir
257
La forma tenedor en los

diagramas de secuencia
Descripcin
Tarea principal
Hacer esto
Hacer esto
Hacer esto
Clase 1:
objeto
Tarea
principal
Clase 2:
objeto
Clase 3:
objeto
Clase 4:
objeto
Hacer
esto
Hacer
esto
Hacer
esto
258
Ejemplo de la forma
tenedor
Descripcin
:Cliente
Direccin:
Direccin de cliente
Obtener direccin
Obtener direccin
Obtener nmero telefnico
259
La forma escalera en los

diagramas de secuencia
Descripcin
Tarea principal
Hacer esto
Hacer esto
Hacer esto
Clase 1:
objeto
Tarea
principal
Clase 2:
objeto
Clase 3:
objeto
Clase 4:
objeto
Hacer
esto
Hacer
esto
Hacer
esto
260
Ejemplo de la forma
escalera
Descripcin
:Cliente
Direccin:
Direccin del cliente
Obtener nmero
telefnico
Obtener telfono
261
Ejemplo: Telfono celular

(marcado)
Dgito: Botn
:Adaptador
DgitoBotn
BotnPresionado( )
Marcador
Display:
DisplayMarcador
:Altavoz
Dgito( )
DespliegueDgito(cdigo )
EmitirTono( cdigo)
El rectngulo que encierra al grupo de

mensajes define una iteracin
Para cada dgito
La condicin del ciclo se muestra en la base del

rectngulo
262

(send)
Mandar:
Botn
:Mandar
AdaptadorBotn
:Marcador
:Celular
Diplay:
DisplayCelular
BotnPresionado( )
Send( )
Conectar( )
EnUso( )
263

(conectar y desconectar)
:Marcador
:Celular
Conectar( )
Crear( )
:Conexin
Conectar( )
ConexinEstablecida( )
Fin( )
Desconectar( )
Desconectar( )
Destruir( )
264
Ejemplo: Cajero automtico

:Interfaz
del cajero
: Cliente
Solicitar NIP
Solicitar monto
y nmero cuenta
:despachador
:retirador
:cuenta
Verificar NIP ( )
retirar ( )
Dar dinero
Proporcionar
saldo ( )
Dar dinero
265
EL MODELO DE DISEO
(DIAGRAMAS DE
ESTADO)
Jorge Kashiwamoto
266
Panormica general
Definir el concepto de Evento,
Actividad y Estado
Comprender las partes de un Estado

y de Transicin
Analizar ejemplos de diagramas de
Estado
Comprender distintos tipos de
diagramas de Estado
267
El modelo de diseo I
Modelo de
requerimientos

Diagrama de clases
(primera versin)
Modelo de
anlisis
Diagrama de clases
(+ paquetes)
Casos de uso
(+ descripciones)
Secuencia de las
operaciones
Estados de las
de la
DE CLASES
interfaz268
1
Asociaciones
Atributos
Modelo de Clases
diseo
Clases
Casos de uso
Representacin del
Comportamiento
Modelado del aspecto Dinmico
Interaccin
Comportamiento de una sociedad de objetos
Mquina de Estados
Comportamiento de un objeto
269
Mquina de Estados
Secuencia de estados del tiempo de vida de
un objeto, suscitados por Eventos
Seales
Operaciones
El paso del Tiempo
Ocurrencia de un
Evento
Dependiendo del
Estado Actual
del Objeto
Ejecucin de
una Actividad
270
Evento
Especificacin de una ocurrencia
significativa que tiene una ubicacin en el
tiempo y el espacio
Ocurrencia de un estmulo que dispara la
transicin de un estado
271
Actividad
Ejecucin no-atmica dentro de una
maquina de estados
Produce
Cambio de Estado
Regresa un valor
Dependiendo del
Estado Actual
del Objeto
Ocurrencia de
un Evento
Ejecucin de
una Actividad
Cambio de Estado
del Objeto
272
Estado
Condicin o situacin de un objeto durante
su tiempo de vida, en la cual
Satisface una condicin
Realiza alguna actividad
Espera la ocurrencia de un evento
La respuesta es afectada por

el pasado
273
Transicin
Relacin de cambio entre 2 estados
Adeudo
Pagar
Pagado
Transicin
274
Visualizacin de una Mquina

de Estados
Por el Flujo de Control
DIAGRAMA DE ACTIVIDAD
Por los Estados Potenciales y sus

Transiciones
DIAGRAMA DE ESTADOS
275
Caractersticas de una
Mquina de Estados
Una mquina de estados bien estructurada
es:
Eficiente
Simple
Adaptable
Entendible
276
Representacin de un Estado
ESTADOS
ESTADO
FINAL
NOMBRE
envo
Solicitado
Entregado
devolucin
ESTADO INICIAL
277
Partes de un Estado
Nombre
Acciones de Entrada/Salida
Transiciones internas
Subestados
Eventos Diferidos
Actividad
Solicitado
entry/ ponBitcora(PrdCve,SolEnt)
exit/ponBitcora(PrdCve,SolOut)
nuevoDestinatario / Producto.CambiaDest()
do / EsperaMensajera
descuentaInv / defer
278
Partes de una Transicin

Estado Origen
Disparador de evento
Event Trigger
Condicin de transicin
Guard Condition
Accin
Estado Destino
279
Partes de una transicin

EVENTO DE TIEMPO ENVO DE SEAL
despues(24 horas)/send o.RevExist
AUTOTRANSICIN
DISPARADOR
TRANSICIN SIN
DISPARADOR
Solicitado
EnInventario pedido
ConProveedor
Autoriza(PrdCve)
[cobroValido]
Pagado
Entregado
envo
/ m.AgregaEnvo
ACCIN
GUARD CONDITION
DISPARADOR DE EVENTO CON PARAMETROS
280
Subestados secuenciales
TRANSICION DE/A
ESTADO COMPUESTO
ESTADO COMPUESTO
SUBESTADO SECUENCIAL
Activo
insertarTarjeta
Validando
Desocupado
[continuar]
cancelar
mantener
Seleccionando
Procesando
[no continuar]
Mantenimiento
TRANSICION DE
SUBESTADO
entry/leerTarjeta
exit /expulsarTarjeta
Imprimiendo
281
Subestados histricos
ESTADO INICIAL PARA
LA PRIMERA ENTRADA
Respaldando
Comando
consulta
Acumulado
Copiado
ESTADO HISTRICO
SHALLOW
Borrado
282
Subestados concurrentes
SUBESTADOS
CONCURRENTES
Desocupado
JOIN
ESTADO
COMPUESTO
mantener
FORK
Mantenimiento
Probando
Probando
Dispositivos
Ordenando
Auto
Diagnsticos
[continuar]
Esperando
Comando
keyPress
[no continuar]
283
EL MODELO DE DISEO
(DIAGRAMAS DE
COLABORACIN)
Jorge Kashiwamoto
284
Panormica general
Comprender la utilizacin de los
diagramas de colaboracin:
Fundamentos
Relacin con Diagramas de Secuencia
Elementos
Flujos de Control
Usos
Pasos de la Aplicacin Metodolgica

285
Diagrama de colaboracin
Tipo de diagrama de interaccin
Modela el aspecto dinmico

Interaccin = Conjunto de objetos y sus
relaciones (mensajes)
Enfatiza la Organizacin Estructural de los
objetos que mandan y reciben mensajes
286
Elementos de un diagrama de
colaboracin
Objetos
Ligas
Mensajes
287
Elementos
objeto
c:Cliente
liga o
enlace
<<local>>
1: <<crea>>
2: ponAcciones(a,d,o) estereotipo
3: <<destruye>>
de ruta
mensaje
:Transaccin
{transient}
objeto
<<global>>
p:ODBCProxy
2.1: ponValores(d,3.4)
2.2: ponValores(a,CO)
secuencia
288
Diferencias con el diagrama

de secuencia
Primera
RUTA
Cmo un objeto se liga con otro
<<local>> el objeto es local al objeto cliente

<<global>>
<<parameter>>
<<self>>
289
Diferencias con el diagrama

de secuencia
Segunda
NUMERACIN DE LA SECUENCIA
Indicacin del Orden de Ejecucin
Se precede cada mensaje con un nmero
Numeracin decimal Dewey para subsecuencias
290
Flujos
Flujo Secuencial de Control
Flujos Complejos
Iteracin
Precediendo con
*
*[ i := 1..n]
Salto
[condicin_booleana]
Ramas con la misma numeracin
Las expresiones pueden ser pseudocdigo o de algn

lenguaje en particular.
291
Equivalencia semntica
Los diagramas de colaboracin y de
secuencia tienen equivalencia semntica.
Aunque no necesariamente explcitamente
visualicen la misma informacin.
292
Cundo usar diagramas de

colaboracin?
Enfatizar las relaciones estructurales entre
las instancias de la interaccin (mensajes)
Visualizar iteraciones y saltos complejos
Visualizar mltiples flujos concurrentes de
control
293
Pasos
1. Establecer el contexto
(sistema, subsistema, operacin, clase,
escenario de caso de uso, colaboracin)
2. Identificar los objetos.

Colocarlos como vrtices
Los objetos ms importantes van al centro
294
Pasos
3. Establecer los valores iniciales de cada uno de
estos objetos
(valores, estados, roles, instanciacin mltiple become,
copy -)
4. Especificar la liga entre los objetos y los

mensajes a ser utilizados
4.1 Trazar las ligas de asociacin: Conexiones
estructurales
4.2 Trazar otras ligas y catalogarlas con Estereotipos de
Ruta (global, local)
295
Pasos
5. Iniciar el trazo de mensajes
5.1 Comenzar con el mensaje que inicia la interaccin
5.2 Aadir mensajes subsecuentes
5.3 Aplicar la secuencia de numeracin
6. Si es necesario, aplicar restricciones de tiempo o

espacio.
7. Un control ms formal implica precondiciones y
postcondciones para cada mensaje.
296
Otros consejos
Usualmente los diagramas de secuencia
muestran un flujo de control
Tpicamente, se tienen varios diagramas de
interaccin
Primarios
Rutas alternativas
297
2: agregarEstudiante(s)
r:RegistrarAgente
1: <<crear>>
3: registrar()
3.1: obtenItinerario()
<<local>>
{self}
s:Estudiante
registrado = False
3.2: agrega(s)
c1:Curso
:Escuela
s:Estudiante
registrado = False
3.4: <<become>>
3.3: agrega(s)
c2:Curso
{association}
{association}
298
Diagramas de Interaccin
Bien Estructurados
Se enfoca en un aspecto de la dinmica del sistema
Contiene solamente aquellos elementos que son
esenciales para entender un aspecto del sistema
Provee detalles consistentes con su nivel de
abstraccn y aquellos adornments esenciales
No es demasiado general ni exageradamente
detallado
299
EL MODELO DE DISEO
(DIAGRAMAS DE
ACTIVIDAD)
Jorge Kashiwamoto
300
Panormica general
diagramas de Actividad:
Fundamentos
Relacin con Diagramas de Secuencia
Elementos
Flujos de Control
Usos
Pasos de la Aplicacin Metodolgica

301
Diagrama de actividad
Muestra el Flujo de Actividad a Actividad
Modela el aspecto dinmico de una sociedad

de objetos
Modelado de pasos
Secuencia (de un procedimiento computacional)
Concurrente
302
Diagrama de actividad (2)

Modela el Flujo de un Objeto, de cmo se
mueve de un estado a otro en los diferentes
flujos de control.
Comprando con D. de Interaccin:
D.Interaccin: Flujo de control de objeto a
objeto.
D.Actividad: Flujo de control de actividad a
actividad.
303
Actividad
Ejecucin no atmica dentro de una
mquina de estados.
Las actividades resultan en una Accin
(clculos atmicos ejecutables):
Cambio de Estado
Regreso de un Valor
304
Acciones
Agrupan a
La llamada a otra operacin
Enviar una seal
Crear o destruir objetos
Clculos puros
V.g.: Evaluar una expresin
305
Ejemplo
estado inicial
Seleccionar Lugar
Comisionar Arquitecto
Desarrollar un Plan
estado de accin
estado de
actividad con
submquina
Autorizar Plan
salto secuencial
[no aceptado]
fork concurrente
[else]
Elaborar Construccin
Hacer Negociaciones()
join concurrente
Finalizar Construccin
estado final
:Escrituras
[Completo]
flujo de objeto
306
Estados Accin
Representan una accin
No pueden descomponerse, es atmico

No puede interrumpirse
Tiempo de ejecucin insignificante
307
Estados Accin
expresin
Autorizar Plan
accin sencilla
i := Sqrt(j) + 1
308
Estados Actividad
Pueden descomponerse
Su actividad est respresentada por otros
diagramas de actividad
No son atmicos, pueden interrumpirse
Se considera que toma algn tiempo en
ejecutarse
Un Estado Accin es un subcaso del Estado
Actividad
309
Estados Actividad
Estado Actividad =
+ Estados Accin
+ Estados Actividad
Partes
Accin de Entrada
Accin de Salida
Especificaciones de Submquina
310
Estados Actividad
Hacer construccin
entry/Bloquea()
Procesar Factura(f)
Accin de Entrada
Submquina
311
Transiciones
Es el paso de un estado accin o actividad a
otro, una vez que ste se ha completado.
Se representan con lneas con puntas de
flecha dirigidas
Se denominan de tipo sin disparador o

triggerless.
312
Saltos
Especificacin de rutas alternativas basadas
en expresiones Booleanas.
Se representa con un rombo a partir del
cual, se tienen ms de una transicin
alternativa especificadas con Guard
Conditions entre corchetes.
Se usa la palabra reservada else
Pueden modelarse iteraciones.
313
Fork / Join
Modelar actividades concurrentes
Pueden anidarse
Se representan con lneas horizontales a
partir de las cuales salen las transiciones
iniciales o llegan las finales de los estados
concurrentes.
314
Swimlanes
Grupos o particiones de estados de
actividad segn la organizacin de negocio
responsable.
Modelar flujos de trabajo de Procesos de
Negocio.
Se representan con rectngulos etiquetados

con la unidad organizacional dentro de los
cuales se agrupan los estados.
315
Flujos de Objeto
Modela los objetos (particulamente con
estado) que pasan de un estado a otro.
Se representa como se hace
convencionalmente en UML y se une con
lneas rayadas dirigidas entre los estados.
316
Aplicacin Metodolgica
para Flujos de Trabajo
1. Establecer el foco del flujo de trabajo
2. Seleccionar los objetos de negocio de alta
nivel de responsabilidad
3. Identificar las precondiciones para el
estado inicial y las postcondiciones para el
estado final
4. Se trazan los elementos
317
Flujos de Trabajo
5. Para acciones o conjunto de acciones
complicadas, se colapsan en estados
Actividad.
6. Trazar las transiciones, comenzar con las
secuenciales, saltos y concurrentes en este
orden.
7. Se grafican los objetos importantes con
sus valores o estados.
318
Ejemplo
Cliente
Ventas
Contabilidad
Almacn
Solicita
Devolucin
Dar
Folio
Enviar
Artculo
Recibir
Artculo
i:Artculo
[Regresado]
Resurtir
Artculo
Registrar
i:Artculo
[Disponible]
319
Aplicacin Metodolgica para

Operaciones
1. Se agrupan las abstracciones
involucradas en la operacin (parmetros,
atributos y clases)
2. Identificar precondiciones al estado inicial
y postcondiciones al estado final.
3. Comenzar con el trazado de estados.
4. Especificar saldos y concurrencia.
320
EL MODELO DE
IMPLANTACIN
(DIAGRAMAS DE
COMPONENTES)
Jorge Kashiwamoto
321
Panormica general
diagramas de componentes:
Fundamentos
Relacin con Clases
Relacin con Interfaces
Reemplazo Binario
Tipos
Ejemplos
322
Diagrama de Componentes
Modelado de Aspectos Fsicos del Sistema
Muestra de un conjunto de componentes

la Organizacin, y
la Dependencia
Modela una vista de implantacin esttica

de un sistema
323
Involucra el modelado de cosas fsicas que
residen en un NODO
Ejecutables
Bibliotecas
Tablas
Archivos
Documentos
324
Definicin
Visualiza
Un conjunto de componentes y
Sus relaciones
Grficamente es un conjunto de
Vrtices
Arcos
325
Componente
Parte fsica y reemplazable de un sistema
que conforma la realizacin de un conjunto
de interfaces
kernel32.dll
326
Nombre de un componente
Interfaz (Servicios)
FraudAgent.dll
agent.java
Realizes
FraudAgent
FraudPolicy
FraudSearch
system::dialog.dll
{versin=2.1.75}
RUTA (V.g. Paquete)

327
Componentes y Clases
Semejanzas
Nombre
Realizan un conjunto de interfaces
Participan en relaciones de
Dependencia
Generalizacin y
Asociacin
Anidarse
Tienen instancias
Participan en interacciones
328
Representacin fsica
Representacin lgica
Empaquetamiento
fsico
Nivel de abstraccin
Operaciones a travs
de interfaces
Acceso a atributos y
operaciones
329
Diferencias
Residen en un nodo
Otro Caso
Implementacin fsica
de un conjunto de
elementos lgicos
(clases y
colaboraciones)
Diseo lgico
contenible en otros
elementos
Servicios configurables
Servicios disponibles
solo por interfaces
330
FraudAgent.dll
COMPONENTES
PatternSearch
FraudAgent
FraudPolicy
CLASES
331
Componentes e Interfaces
Interfaz
Coleccin de Operaciones que utilizada para
especificar un servicio de una clase o
componente.
Son el pegamento entre los diferentes
componentes (se requiere infraestructura
basada en componentes del sistema operativo)
COM+
CORBA
Enterprise Java Beans
332
Componentes e Interfaces
Descomposicin de la Implementacin Fsica
Proveer componentes que realicen las

interfaces
Este mecanismo permite implantar sistemas
cuyos servicios son location-independent, o
remplazables.
333
FORMA ICNICA
image.java
component.java
ImageObserver
FORMA EXPANDIDA
image.java
<<interface>>
ImageObserver
abort: int {final static}
error: int {final static}
component.java
imageUpdate():Boolean
334
Reemplazo binario
Partes reemplazables binarias en el Sistema
Operativo
No implican reconstruccin o recompilacin
inmediata
Extensibilidad a travs de interfaces
335
Reemplazo binario
Un componente es
Fsico
Reemplazable
Sustituible
Mismas Interfaces
Parte del Sistema

Arquitectura
Tecnologa
Conforma y provee un conjunto de interfaces

336
Tipos de Componentes
De Implantacin
Necesarios y suficientes para generar sistemas ejecutables
.EXE
.DLL o equivalente
Tablas, Pginas Web dinmicas, modelos de objetos, otros
ejecutables, etc.
Productos de Trabajo
Fuentes
Archivos de Datos
De Ejecucin
Aquellos que slo existen en el ambiente de ejecucin
Objeto COM+ instanciado
337
Elementos Estndares
Ejecutable (Executable)
Biblioteca (Library)
Esttica o Dinmica
Tabla (Table)
Archivo (File)
Documento (Document)
338
Modelado de Ejecutables y
Bibliotecas
animator.exe
dlog.dll
{versin=5.0.1}
render.dll
wrfrme.dll
raytrce.dll
339
Modelado de Tablas, Archivos

y Documentos
animator.hlp
dlog.dll
animator.exe
{versin=5.0.1}
animator.ini
render.dll
wrfrme.dll
raytrce.dll
shapes.tbl
340
Modelado de APIs
animator.exe
{versin=5.0.1}
IScripts
IRendering
IApplication
IModels
341
Modelado de Cdigo Fuente

render.h
{versin=5.3}
render.cpp
{versin=5.3.7}
rengine.h
{versin=4.6}
poly.h
{versin=4.1}
colortab.h
{versin=4.1}
342
EL MODELO DE
IMPLANTACIN
(DIAGRAMAS DE
IMPLANTACIN
o
DEPLOYMENT)
Jorge Kashiwamoto
343
Panormica general
diagramas de Deployment:
Fundamentos
Nodos
Relacin con componentes
Paquetes
Conexiones
Atributos
Usos
344
Diagramas de Deployment
Modelado de los Aspectos Fsicos del
Sistema
Junto con el de componentes son los 2
diagramas en este nivel
Muestra la configuracin de los nodos de

procesamiento en tiempo de ejecucin y los
componentes residentes en ellos
345
Modela una vista de implantacin esttica
Modela la topologa del hardware donde se

ejecuta la aplicacin
Esencialmente son diagramas de clase
enfocados a nodos en el sistema
346
Visualiza el aspecto esttico de los nodos fsicos y
sus relaciones; as como los detalles de su
Modem bank
construccin
Internet
Nodos
<<processor>>
caching server
<<processor>>
caching server
Nodos
Conexin
<<network>> local network
<<processor>>
primary server
<<processor>>
server
<<processor>>
server
<<processor>>
server
347
Elementos de un
Diagrama de Deployment
Nodos
Relaciones de
Dependencia
Asociacin
348
Nodo
Elemento fsico que existe en tiempo de
ejecucin y representa un recurso
computacional
mi_server
Nombre
349
Nombres de Nodo
Nombres extendidos
ventas
Nombres simples
Deploys
pos.exe
contacts.exe
mi_server
Package
server::backup
{remoteAdministrationOnly}
350
Semejanzas entre
Nodos y Componentes
Nombres
Relaciones
Dependencia
Generalizacin
Asociacin
Anidarse
Tener instancias
Participar en interacciones
351
Diferencias entre
Nodos y Componentes
Ejecutan componentes
Representan la
implantacin fsica de
componentes
Participan en la
ejecucin de un
sistema
Representan el
empaquetamiento
fsico de otros
elementos lgicos
352
Relacin entre nodos y

componentes
ventas
pos.exe
contacts.exe
353
Nodos y Paquetes
Los nodos pueden ser agrupados en
paquetes
Servidores
server_1
server_backup
354
Conexiones
Asociaciones entre nodos
cajero
Conexin
<<10-T Ethernet>>
server
consola
RAID Array
<<RS-232>>
355
tributos y adornments
:cajero
Deploys
user.exe
<<10-T Ethernet>>
s : server
processorSpeed = 300 MHz
memory = 128 Mb
c: consola
Deploys
admin.exe
config.exe
:RAID Array
Deploys
dbadmin.exe
tktmstr.exe
<<RS-232>>
356
Usos comunes
Modelado de
Sistemas Embebidos
Sistemas Cliente / Servidor
Sistemas Distribuidos
357
INTRODUCCIN AL
PROCESO UNIFICADO
DE DESARROLLO DE
SOFTWARE
Jorge Kashiwamoto
358
Panormica general
Conocer la existencia de una
propuesta de proceso unificado de
desarrollo
Conocer la arquitectura del proceso
de desarrollo
Apreciar la importancia, ventajas y
desventajas de este tipo de proceso
de desarrollo
359
Metodologa
LENGUAJE
V.g.: UML
PROCESO
V.g.: Rational Unified Process
HERRAMIENTA
V.g.: Rose
360
PROCESO
Elementos de Proyecto
Fases
Etapas
Mtodos
Tcnicas y
Prcticas
Que las personas realizan para desarrollar y

mantener software con sus artefactos asociados
361
RUP
Rational Unified Process
Proceso unificado de desarrollo de software
Caractersticas
Proceso de Desarrollo de Software
Dirigido por Casos de Uso
Centrado en la Arquitectura
Iterativo e Incremental
362
Iterativo e Incremental
Inception
Elaboration
Transition
Construction
363
Rational Unified Process

(RUP)
Objectory Process y otros (Dic98)
4 Fases
9 Flujos de Trabajo
Iteraciones
364
RUP
365
Trabajadores (Workers)
Personas que participan en el proceso
Tienen competencias especficas

En cada flujo de trabajo
Worker
366
Trabajadores (2)
1. Analista de Sistemas
2. Especificador de Casos de Uso
3. Arquitecto
4. Ingeniero de Casos de Uso
5. Ingeniero de Componentes
6. Integrador de Sistemas
7. Diseador de Pruebas
8. Ingeniero de Pruebas de Integracin
9. Ingeniero de Pruebas del Sistema
367
Analista de Sistemas
Responsable del conjunto de requisitos
modelados en los casos de uso
Requisitos funcionales y no funcionales
Delimitar el sistema
Analista de
Sistemas
Flujos de Trabajo
Requerimientos
Encontrar actores y casos de uso
Asegurar modelos de casos de uso completos

y consistentes
Elaborar un glosario para mantener la
consistencia semntica
Dirigir el modelado
Coordinar la captura de requisitos
368
Especificador de Casos de
Uso
Responsable de la descripcin detallada
de un caso de uso
Establecer una comunicacin estrecha
y eficaz con los usuarios (directos)
Especificador
de C.U.
Flujos de Trabajo
Requerimientos
369
Diseador de Interfaces
Disear las interfaces de usuario
Aspecto visual
Diseador de
Interfaces
Desarrollar prototipos de interfaces de

usuario para algunos casos de uso
Flujos de Trabajo
Requerimientos
370
Arquitecto
Requerimientos
Describir la arquitectura y prioridades del
modelo de casos de uso
Anlisis
Garantizar la integridad del modelo de anlisis
Arquitecto
Correcto, consistente y legible
Flujos de Trabajo Diseo

Garantizar la integridad de los modelos de
Requerimientos
diseo y despliegue
Anlisis
Implantacin
Diseo
Garantizar la integridad del modelo de
Implantacin
implantacin
Asignar componentes a nodos
371
Ingeniero de Casos de Uso

Anlisis
Mantener la integridad de las realizaciones
de casos de uso
Diseo
Ingeniero
de C.U.
Flujos de Trabajo
Anlisis
Diseo
Detallar las realizaciones de casos de uso

Verificar la correspondencia entre anlisis y
diseo
372
Ingeniero de Componentes
Anlisis
Definir y mantener las responsabilidades,
atributos, relaciones y requisitos especiales de
una o varias clases del anlisis
Diseo
Ingeniero de
Componentes
Definir y mantener las operaciones, mtodos,

atributos, relaciones y requisitos de implantacin
de una o ms clases del diseo
Flujos de Trabajo Implantacin

Definir y mantener el cdigo fuente de uno o
Anlisis
varios componentes
Diseo
Pruebas
Implantacin
Desarrollar componentes de prueba que
Pruebas
automatizan algunos de los procedimientos de

prueba
373
Integrador de Sistemas
Planificar la secuencia de
construcciones necesarias en cada
iteracin
Integrador de
Sistemas
Integrar cada construccin a partir de

sus partes implementadas
Flujos de Trabajo
Implantacin
374
Diseador de Pruebas
Garantizar la integridad del modelo de
pruebas
Planear las pruebas
Diseador
de Pruebas
Flujos de Trabajo
Pruebas
Establecer objetivos de prueba apropiados
Seleccionar y describir casos de prueba

y los procedimientos de prueba
375
Ingeniero de Pruebas de
Integracin
Ejecutar las pruebas de integracin
Verificar el correcto funcionamiento de
componentes
Ing. de Pruebas Documentar los defectos
de Integracin
Flujos de Trabajo
Pruebas
376
Ingeniero de Pruebas del

Sistema
Ejecutar las pruebas del sistema para
cada iteracin completa
Verificar los resultados en conjunto con
los usuarios finales
Ing. de Pruebas
del Sistema
Flujos de Trabajo
Pruebas
Documentar los defectos

Facilidad para tener familiaridad con el
comportamiento observable del sistema
377
Ventajas de un Proceso
Process Know-How Toma de Decisiones
Estadarizacin
Calidad y Mejores prcticas
Mantenimiento
Control de Complejidad
Control de Proyecto
Reduccin de Costos
378
Ventajas de RUP
Aplicacin de Principios de Ingeniera
Desarrollo
Iteratividad
Orientado a Requerimientos
Basado en Arquitectura
Retroalimentacin
Prototipado
Definicin de Producto
379
Desventajas de RUP
Solamente es un Proceso
No tiene Soporte Multiproyecto
Influencia de los Fabricantes de Herramientas
Carencias en:
Mtrica
Reuso
Control de Personal
Control de Pruebas
380

Analisis y Diseo Orientado A Objetos

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Analisis y Diseo Orientado A Objetos

Diunggah oleh

Hak Cipta:

Format Tersedia

ANLISIS Y DISEO

Panormica general del curso

Captulo 2: Historia de la orientacin a objetos

Panormica general del curso

Captulo 8: Modelo de diseo (diagramas de estado)

Captulo 12: Modelo de implantacin (diagramas de

Panormica general del curso

Panormica general del curso

En clase se presentarn algunos ejemplos para

Material de consulta (1)

Anlisis y Diseo Orientado a

Booch, G., J. Rumbaugh y I.

Material de consulta (2)

notation guide. Version 1.1.

Rational Software, 1997. UML

semantics. Version 1.3.

Material de consulta (3)

Booch, G., J. Rumbaugh y I. Jacobson. El

Evaluacin del curso

Los sistemas tienen:

Existencia del Lmite de

4 razones para la complejidad

4 razones para la complejidad

5 atributos de los sistemas

5 atributos de los sistemas

Con esta tcnica se solventa

Se aplica para descomponer un

El proceso resultante toma la

Un ejemplo es la metodologa estructurada

Alcanz su pico de popularidad entre 1985-1989

La vida media para las

Aspectos histricos (1)

Aspectos histricos (2)

Aspectos histricos (3)

Aspectos histricos (4)

Aspectos histricos (5)

Mediados de los 1990s (1)

La tecnologa de BDOO tiene un xito sin

Mediados de los 1990s (2)

Existen muchos enfoques de desarrollo de

Mediados de los 1990s (3)

Mediados de los 1990s (4)

A finales de los 1990s

Existe un crecimiento significante

Lo que se ha aprendido (1)

Lo que se ha aprendido (2)

Lo que se ha aprendido (3)

Lo que se ha aprendido (4)

Herencia y herencia mltiple

Metas u objetivos en un clculo

Determinado marco conceptual

Apropiado para el desarrollo de aplicaciones

Donde el anlisis de la complejidad juega el papel

Representar explcitamente los aspectos comunes dentro de

Construir especificaciones fciles de cambiar o adaptar

Los objetos renen las caractersticas

La orientacin a objetos (OO)

Entidad discreta con lmites e identidad bien delimitadas

Abstraccin (Resumen 1/2)

Abstraccin (Resumen 2/2)

Lo que un observador concibe no necesariamente

Descriptor para un conjunto de objetos que

Tipo de dato abstracto