Contenido Didáctico Del Curso 200609

ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA
Contenido Didctico del Curso 200609

Lenguaje de Modelado Unificado - UML

1

MODULO LENGUAJE UNIFICADO DE MODELADO UML
ELABORADO

Harold Cabrera Meza

ACTUALIZADO POR
Nilson Albeiro Ferreira Manzanares

CORRECTOR DE ESTILO
Laura Fabiola lvarez Morales
Instituto Virtual de Lenguas - INVIL

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
2013

2

TABLA DE CONTENIDO

PRIMERA UNIDAD .............................................................................................. 10
UNIDAD 1. INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO ...... 11
CAPITULO 1. QU ES UML? ........................................................................... 11
Leccin 1. Por qu Aprender UML? ............................................................... 12
Leccin 2. UML no es un mtodo .................................................................. 13
Leccin 4. Beneficios de Esta Tecnologa ..................................................... 15
Leccin 5. En donde Utilizamos UML ............................................................ 16
CAPITULO 2. MODELOS ................................................................................. 17
Leccin 6. Modelos ....................................................................................... 17
Leccin 7. Notas y Dependencias ................................................................. 18
Leccin 8. Elementos comunes a todos los diagramas .................................. 19
Leccin 9. Fases de Desarrollo ..................................................................... 20
Leccin 10. Herramientas Para Modelado ..................................................... 21
CAPITULO 3. MODELADO ESTRUCTURADO ................................................ 24
Leccin 11. Bloques de Construccin de UML ............................................... 25
Leccin 12. Diagramas .................................................................................. 33
Leccin 13. Diagramas de Clase ................................................................... 35
Leccin 14. Caractersticas avanzadas de las clases y relaciones ................ 38
Leccin 15. Herencia y polimorfismo ............................................................. 46
SEGUNDA UNIDAD ............................................................................................. 48
UNIDAD 2. CARACTERSTICAS DEL MODELADO UML ................................... 49
CAPITULO 4. DIAGRAMAS UTILIZADOS EN UML ......................................... 49
Leccin 16. Diagramas de Objetos ................................................................ 49
Leccin 17. Diagramas de Casos de Uso ...................................................... 50
Leccin 18. Diagramas de Interaccin ........................................................... 54
Leccin 19. Diagrama de Secuencia.............................................................. 55
Leccin 20. Diagrama de Colaboracin ......................................................... 56

3
Leccin 21. Diagramas de Actividades .......................................................... 57
CAPITULO 5. MODELADO DINMICO ............................................................ 61
Leccin 22. Eventos y seales ....................................................................... 61
Leccin 23. Mquinas de Estado ................................................................... 62
Leccin 24. Tiempo y Espacio ....................................................................... 64
Leccin 25. Transicin y Accin .................................................................... 66
Leccin 26. Diagramas de Estado.................................................................. 66
CAPITULO 6. MODELADO ARQUITECTNICO ............................................. 67
Leccin 27. Componentes, despliegue, colaboraciones y patrones ............... 67
Leccin 28. Frameworks ................................................................................ 70
Leccin 29. Diagramas de Componentes ...................................................... 71
Leccin 30. Diagramas de Despliegue .......................................................... 72
Leccin 31. Sistemas y modelos .................................................................... 72
TERCERA UNIDAD.............................................................................................. 74
UNIDAD 3. PRINCIPIOS DE UML ORIENTADO A OBJETOS ............................ 75
CAPITULO 7. DESARROLLO ORIENTADO A OBJETOS CON UML ............. 75
Leccin 32. Visin General ........................................................................... 75
Leccin 33. Fase de Planificacin y Especificacin de Requisitos ................. 76
Leccin 34. Construccin de los diagramas de casos de Uso ....................... 81
Leccin 35. Planificacin de Casos de Uso segn Ciclos de Desarrollo ........ 82
Leccin 36. Fase de Construccin del Modelo .............................................. 83
CAPITULO 8. DIAGRAMAS DE SECUENCIA DEL SISTEMA ......................... 86
Leccin 37. Construccin de un Diagrama de Secuencia del Sistema........... 87
Leccin 38. Creacin de los Diagramas de Interaccin ................................. 90
Leccin 40. Construccin Diagramas de Diseo............................................ 93
Leccin 41. Implementacin y Pruebas .......................................................... 95
Captulo 9. PILARES DE LA ORIENTACIN A OBJETOS .............................. 95
Leccin 42. Abstraccin ............................................................................... 95
Leccin 43. Herencia ..................................................................................... 96
Leccin 44. Polimorfismo ............................................................................... 97
Leccin 45. Encapsulamiento ........................................................................ 98

4
Leccin 46. Relaciones .................................................................................. 99


5

TABLA DE GRAFICAS

FIGURA 1: CREADORES DEL LENGUAJE UML 11
FIGURA 2: EVOLUCIN DEL LENGUAJE UML 14
FIGURA 3: NOTA 18
FIGURA 4: ELEMENTOS 19
FIGURA 5: FASES DE DESARROLLO DE UN SISTEMA SOPORTADO POR UML 20
FIGURA 6: ARGOUML EDITOR UML 22
FIGURA 7: DA EDITOR DE UML 23
FIGURA 8: ELEMENTOS UML 25
FIGURA 9: CLASES 28
FIGURA 10: ATRIBUTOS 29
FIGURA 11: OPERACIONES 29
FIGURA 12: RESPONSABILIDADES 30
FIGURA 13: OBJETOS 31
FIGURA 14: ASOCIACIN 31
FIGURA 15: ROLES 32
FIGURA 16: AGREGACIN 33
FIGURA 17: CONJUNTO DE CLASES 36
FIGURA 18: CONJUNTO DE CLASES EXTRADAS DE UN SISTEMA DE INFORMACIN 37
FIGURA 19: INTERFAZ 38
FIGURA 20: TIPOS DE DATOS 38
FIGURA 21: SEAL 38
FIGURA 22: COMPONENTE 38
FIGURA 23: NODO 39
FIGURA 24: CASO DE USO 39
FIGURA 25: SUBSISTEMA 39
FIGURA 26: NOTACIN 40
FIGURA 27: HERENCIA MLTIPLE 41
FIGURA 28: ASOCIACIN 42
FIGURA 29: INTERFACES 43
FIGURA 30: ABSTRACCIN CON UNA INTERFAZ 43
FIGURA 31: DIAGRAMA DE INTERACCIN ENTRE CLASES 44
FIGURA 32: RELACIN DE CLASES EN NOTACIN 44
FIGURA 33: OBJETO DENTRO RELACIN DE CLASES EN NOTACIN 45
FIGURA 34: ELEMENTOS CONTENIDOS EN EL PAQUETE 45
FIGURA 35: INSTANCIAS 46
FIGURA 36: DIAGRAMA DE OBJETOS 49
FIGURA 37: ACTOR 50
FIGURA 38: CASO DE USO 51
FIGURA 39: LOS ACTORES QUE INTERACTAN CON EL SISTEMA 53
FIGURA 40: CLIENTE PUEDE DEPOSITAR TEMS Y UN OPERADOR PUEDE CAMBIAR LA INFORMACIN DE UN TEM O
BIEN PUEDE IMPRIMIR UN INFORME 53
FIGURA 41: DEPOSITAR TEM 53
FIGURA 42: PETICIN A UN OPERADOR 54

6
FIGURA 43: DISEO COMPLETO DEL DIAGRAMA DE CASOS DE USO 54
FIGURA 44: TRANSICIONES Y ACTIVACIONES 55
FIGURA 45: FLUJO DE CONTROL 56
FIGURA 46: ESTADOS DE ACCIN 58
FIGURA 47: SUBMAQUINAS 58
FIGURA 48: TRANSICIONES 59
FIGURA 49: BIFURCACIONES 59
FIGURA 50: DIVISIN Y UNIN 60
FIGURA 51: CALLES 60
FIGURA 52: SEALES 61
FIGURA 53: EVENTOS 62
FIGURA 54: UN EVENTO DE CAMBIO O DE TIEMPO 62
FIGURA 55: ESTADOS 63
FIGURA 56: TRANSICIONES 64
FIGURA 57: TIEMPO Y ESPACIO 65
FIGURA 58: LOCALIZACIN 65
FIGURA 59: DIAGRAMA DE ESTADOS CON TODOS SUS COMPONENTES 67
FIGURA 60: COMPONENTES 67
FIGURA 61: INTERFAZ 68
FIGURA 62: DESPLIEGUE 68
FIGURA 63: COLABORACIONES 69
FIGURA 64: MECANISMOS 69
FIGURA 65: PLANTILLA FORMADA POR UN CONJUNTO DE ABSTRACCIONES 70
FIGURA 66: FRAMEWORKS 70
FIGURA 67: DIAGRAMA DE COMPONENTES 71
FIGURA 68: DIAGRAMAS DE DESPLIEGUE 72
FIGURA 69: SISTEMAS Y MODELOS 73
FIGURA 70: PLANIFICACIN DE CASOS DE USO SEGN CICLOS DE DESARROLLO 82
FIGURA 71: DIAGRAMA DE SECUENCIA DEL SISTEMA PARA EL CASO DE USO 87
FIGURA 72: DIAGRAMA DE CLASES DE DISEO SENCILLO 91
FIGURA 73: CLASE CON NOMBRE DE RUTA 96
FIGURA 74: HERENCIA 97
FIGURA 75: POLIMORFISMO 98
FIGURA 76: ENCAPSULAMIENTO 98
FIGURA 77: ESTRUCTURA DE ENCAPSULAMIENTO 98
FIGURA 78: TIPOS DE LNEAS QUE SIMBOLIZAN LAS RELACIONES 99
FIGURA 79: ARGUMENTO DE ASIGNATURA 100
FIGURA 80: GENERACIONALES 100
FIGURA 81: ASOCIACIONES 101
FIGURA 82: REALIZACIN 102

7

INTRODUCCIN

Unas de las etapas vitales para un diseador de software, es el anlisis y
diseo de sistemas. El anlisis de sistemas es el proceso de clasificacin e
interpretacin de hechos, diagnstico de problemas y manejo de la informacin para
hacer mejoras al sistema, siendo el diseo la fase de planificacin, reemplazo o
complementacin de un sistema organizacional existente. Para estas fases del
desarrollo de software se han desarrollado diferentes modelos con los cuales se han
obtenido resultados satisfactorios, mas no ptimos puesto que se han sesgado
unos con otros.

Es entonces cuando se plantea la necesidad de crear un mismo lenguaje que
permita modelar sistemas, de manera que se pueda en cualquier momento construir
software partiendo de un solo esquema de modelado, tanto estructural como
orientado a objetos

El Lenguaje Unificado de Modelado (Unified Modeling Lenguaje UML), es un
lenguaje estndar para escribir planos de software, UML se puede utilizar para
visualizar, especificar, construir y documentar los artefactos de un sistema que
involucre una gran cantidad de software. UML prescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos significan.

UML se puede usar para modelar distintos tipos de sistemas: sistemas
de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece
nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo, que
cubre todas las vistas necesarias para desarrollar y luego desplegar tales
sistemas.

El curso acadmico denominado Lenguaje de Modelado -UML- Electiva, est
orientado a hacia el manejo adecuado de las herramientas que ofrece el lenguaje de
modelado orientado a objetos, desde la construccin de los diagramas de interaccin
del sistema, hasta la aplicacin del modelo en un caso real de desarrollo.


8

JUSTIFICACIN

El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica,
un lenguaje de modelado y no un mtodo o un proceso. El UML est compuesto por
una notacin muy especfica y por las reglas semnticas relacionadas para la
construccin de sistemas de software. UML en s mismo no prescribe ni
aconseja cmo usar esta notacin en el proceso de desarrollo o como parte de una
metodologa de diseo orientada a objetos.

El UML soporta un conjunto rico en elementos de notacin grficos. Describe
la notacin para clases, componentes, nodos, actividades, flujos de trabajo, casos de
uso, objetos, estados y cmo modelar la relacin entre esos elementos. UML tambin
soporta la idea de extensiones personalizadas a travs elementos estereotipados
provee beneficios significativos para los ingenieros de software y las organizaciones
al ayudarles a construir modelos rigurosos, trazables y sustentables, que soporten el
ciclo de vida de desarrollo de software completo.

Para los diseadores de software, UML muestra la forma en la cual se
modelan diseos prcticos con los cuales a travs de los casos de usos, diagramas
de interaccin se llega en conjunto con el anlisis al diseo del software de manera
segura sobre casos reales detallados en los diagramas de estados, adems, UML
como lenguaje se implementa en el diseo y en la base de datos, es decir, el diseo
se complementa con pruebas sobre el resultado final del modelo a ser programado.


9

OBJETIVOS

1. Fomentar la realizacin de esquemas que representen al sistema con cierto
grado de complejidad, para as desarrollar software ajustado a sus
necesidades reales.
2. Especificar la estructura y comportamiento de un sistema.
3. Proporcionar diagramas y plantillas que guen en la construccin de un
software orientado a objetos.


10

PRIMERA UNIDAD

INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO

11

UNIDAD 1. INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO

CAPITULO 1. QU ES UML?

El Lenguaje Unificado de Modelado (Unifield Modeling Lenguaje UML), es un
lenguaje estndar para escribir planos de software, UML se puede utilizar para
visualizar, especificar, construir y documentar los artefactos de un sistema que involucra
una gran cantidad de software. UML prescribe un conjunto de notaciones y diagramas
estndar para modelar sistemas orientados a objetos, y describe la semntica esencial
de lo que estos diagramas y smbolos significan.

UML se puede usar para modelar distintos tipos de sistemas como por ejemplo:
sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML
ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo,
que cubre todas las vistas necesarias para desarrollar y luego desplegar tales
sistemas.

UML es slo un lenguaje y por tanto es tan solo una parte de un mtodo de
desarrollo de software, adems, es independiente del proceso, aunque para utilizar
ptimamente se debera usar en procesos que fuesen dirigidos por los casos de uso,
centrados en la arquitectura, lo interactivo e incremental.

Figura 1: Creadores del Lenguaje UML


12
UML es una consolidacin de muchas de las notaciones y conceptos ms usados
orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch,
James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a
objetos ms populares, en 1996, el Object Management Group (OMG), public una
peticin con propsito de un metamodelo orientado a objetos de semntica y notacin
estndares. UML, en su versin 1.0, fue propuesto como una respuesta a esta peticin
en enero de 1997. Hubo otras cinco propuestas rivales.

Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su
trabajo y presentaron al OMG un documento revisado de UML, llamado UML versin
1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG
llama a este documento OMG UML versin 1.1. El OMG estaba actualmente en proceso
de mejorar una edicin tcnica de esta especificacin, prevista su finalizacin para el 1
de abril de 1999.

Leccin 1. Por qu Aprender UML?

Los programadores en los inicios de los sistemas de computacin no realizaban
anlisis fuertes o profundos sobre u problema a resolver, eventualmente realizaban un
bosquejo o medianamente un diagrama con poca tcnica donde se daba a entender una
idea mnima de lo que pensaban realizar en el proceso de programacin. A los
programadores se podran considerar como temerarios en el desarrollo de aplicaciones,
ya que ests se est ajustando segn los requerimientos del momento, significando un
alto riesgo para las empresas o entidades donde se realice los proyectos. En la
actualidad este procedimiento se considera un problema de alto riesgo para los
negocios.
Por tal razn los sistemas de informacin en la actualidad parten de un anlisis y
diseo muy bien evaluado, donde el cliente reconozca y entienda a detalle lo que el
grupo de programadores realizar y que este pueda sugerir cambios que permitan
cumplir con las necesidades o cambiar de opinin frente a un proceso y aplicarlo de otra
manera en el sistema, una vez el diseo sea claro y que sea de completo
consentimiento del cliente, el grupo de trabajo proceder a desarrollar la solucin tal cual
como se dise.
A medida que el mundo evoluciona este se vuelve ms complejo y los sistemas
de informacin aumentan su complejidad y se debe dar respuesta a las necesidades que
se presenten. Es de reconocer que todo influye en un sistema de informacin: el
hardware, software, internet, redes, base de datos y muchas ms variables que
intervienen en el proceso y que se evidencian en grandes cantidades de informacin.
Es por ello que si desea crear un sistema en la actualidad, se deber partir con la
pregunta: Cmo se manejara un nivel tan alto de complejidad?
UML es la respuesta, pues mediante este lenguaje se organizar el proceso de
diseo donde los analistas, clientes, desarrolladores y todo el equipo de trabajo que

13
intervenga en el proyecto, comprendern y participar en la mejor solucin al problema
presentado, enfrentando la complejidad que se presente y se resuelva de una manera
organizada. Por ejemplo: un carro, un avin un edificio, parten de un diseo (Dibujo) muy
detallado y aunque estos resultados se evidencian de forma tangible, no significa que un
sistema de informacin que es intangible no cuente con su propio diseo, por el
contrario, si dicho sistema cuenta con una buena planificacin en su diseo, obtendr un
excelente resultado para el usuario final.
Tambin es importante tener claro, que un sistema de informacin que cuente con
un buen diseo (dibujo), permitir realizar fcilmente futuras modificaciones de manera
puntual y precisa, ahorrando tiempo y dinero en el proceso de actualizacin en la
programacin de una solucin anteriormente diseada.

Leccin 2. UML no es un mtodo

Inicialmente los mtodos son una tcnica para llevar a cabo una accin, UML es
un compendio de modelos que pueden ser interpretados de forma directa a una gran
variedad de lenguajes de programacin como Java, C++ o Visual Basic, e incluso a
tablas en una base de datos relacional o una base de datos orientada a objetos.

UML se construye con modelos estndar sobre anlisis y diseo de sistemas
orientados a objetos. De los ms populares se incluyen los siguientes:

Catlisis: Un mtodo orientado a objetos que fusiona mucho del trabajo
reciente en mtodos orientados a objetos, y adems ofrece tcnicas especficas para
modelar componentes distribuidos.

Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por
Ivar Jacobson.

Shlaer/Mellor: El mtodo para disear sistemas de tiempo real, puesto en marcha
por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos,
modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando el
mundo en Datos (Prentice Hall). Shlaer/Mellor continan actualizando su mtodo
continuamente (la actualizacin ms reciente es el OOA96 report), y
recientemente publicaron una gua sobre cmo usar la notacin UML con Shlaer/Mellor.

Fusin: Desarrollado en Hewlett Packard a mediados de los noventa como
primer intento de un mtodo de diseo orientado a objetos estndar. Combina OMT
y Booch con tarjetas CRC y mtodos formales. (www.hpl.hp.com/fusion/file/teameps.pdf)

OMT: La Tcnica de Modelado de Objetos fue desarrollada por James
Rumbaugh y otros, y publicada en el libro de gran influencia "Diseo y Modelado
Orientado a Objetos" (Prentice Hall, 1991). Un mtodo que propone anlisis y diseo

14
interactivo, ms centrado en el lado del anlisis.

Booch: Parecido al OMT, y tambin muy popular, la primera y segunda edicin
de "Diseo Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y
1994),

(Object-Oriented Design, With Applications), detallan un modo ofreciendo
tambin diseo y anlisis 'iterative', centrndose en el lado del diseo.

Leccin 3. Evolucin del Lenguaje UML

Figura 2: Evolucin del Lenguaje UML


15
Desde su indicio ya se evidenciaba un buen grado de precisin que ha tenido el
lenguaje de modelado unificado UML, donde muchas de las mejores tcticas en diseo
le pertenecen y se espera que este lenguaje sea la base de muchas herramientas
aplicadas al modelamiento visual, simulacin y desarrollo de diferentes ambientes, a
medida que estas aplicaciones implementen ms desarrollos.

Se deben tener en cuenta dos aspectos muy importantes en el Unificado que se
logra con UML. Primero, elimina gran parte de las diferencias entre los diferentes
lenguajes de modelado y mtodos previos. Segundo, unifica las diferentes perspectivas
de diferentes clases de sistemas, fases de desarrollo y concretos internos.

Es de destacar del xito de este lenguaje en diversos proyectos de excelentes
resultados y el crecimiento de herramientas de apoyo y gran variedad de libros de
aprendizaje.

Como el proceso de aprendizaje debe de ser constante y dentro del e mdulo no
es prudente entrar a mediar otros temas diferentes, por ello se registran las siguientes
siglas que sern una incgnita que deber responde cada uno de los futuros ingenieros
MSF, RUP, DSL, OMG e IBM y mirar hacia donde se inclinaran en el caso de que
consideren que el lenguaje UML no cumple sus requerimientos.

Leccin 4. Beneficios de Esta Tecnologa

AL utilizar el lenguaje de modela los beneficios son diversos, entre estos tenemos:
1. Minimizar Costos: esto se evidencia segn el tamao de la organizacin donde
se aplique y un buen desarrollo del diseo.
2. Calidad: La aplicacin del lenguaje UML hace necesario la participacin del
usuario en la definicin de requerimientos y por ende mejora notablemente un
sistema segn sean las necesidades del usuario. El mantenimiento correctivo
y/o reparaciones se reduce drsticamente. Algo similar ocurre en los
proyectos de reingeniera.
3. Mejor soporte a la planeacin y al control de proyectos. Al desarrollarse un
buen plan de trabajo donde todo un equipo de trabajo al igual que el mismo
cliente han intervenido en el desarrollo, permite estandarizar distintas fases del
proyecto y ser evaluado de una manera fcil por usuarios distintos al
programador y permitiendo la toma de decisiones de una manera gil y
oportuna.

4. Mayor independencia del personal de desarrollo o programadores. Tambin
parte de un buen diseo donde todo este bien documentados permite que el
equipo de desarrollares entiendan con facilidad el sistemas y puedan tener
movilidad en el proyecto si verse este afectado en su calidad, ya que con

16
anterioridad se tienen conocimiento la labor que se va a desarrollar y no se
improvisara en el proceso.
5. Mayor soporte al cambio organizacional, comercial y tecnolgico. Con UML
todos los cambios que se considere para un sistema, pueden ser probados
primero en papel y segn los resultados que arrojen en la planificacin y
diseo se cuantificara el impacto que generen los cambios realizados antes de
aplicarlo directamente en el sistema, permitiendo probar diferentes alternativas
y seleccionar la ms favorable para el cliente.
6. Alto reus. Regularmente los sistemas comparten ciertas similitudes y es muy
probable que partes de un diseo y rutinas de programacin puedan ser
usadas por sistema, a este se le denomina reus que en ocasiones esta
favorece una administracin adecuada, un bajo costo y la minimizacin de
errores.

7. Mejores tiempos totales de desarrollo (de 50% o ms). Si se cumple con los
pasos anteriores el tiempo de desarrollo baja drsticamente y se podra en
considerar que se tendra un ahorro hasta del 50% segn el tamao del
sistema. Es por ello que es de suma importancia realizar un anlisis a
profundidad y dedicar el tiempo necesario para el diseo y as en las etapas
de construccin, implementacin y estabilizacin se aminore el tiempo ya que
los errores fueron corregidos en las fase de mayor impacto con el sistema.

Leccin 5. En donde Utilizamos UML
Partamos recordando que el Lenguaje de Modelado Unificado UML, es para hacer
modelos que faciliten visualizar como es y cmo queremos un sistema. Este modelado
es una plantilla que se usara como gua para el desarrollo de un sistema y as dejar
documentado todo el proceso de produccin del mismo.

Banco y servicios financieros
Telecomunicaciones, transporte
Defensa/industria aeroespacial
Electrnica mdica
mbito cientfico
Tambin se pueden modelar workflows en un sistema jurdico, diseo de
hardware, etc.
Estas son algunas de las reas donde el UML es utilizado, debido a que no es permitido
que el sistema aplicado al control de una de estas instituciones presente errores que le
puedan afectar a la concurrencia de clientes o perdida econmica a la misma institucin
que la pudiese afectar fuertemente.

17
CAPITULO 2. MODELOS
Un modelo representa a un sistema software desde una perspectiva especfica. Al
igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma
figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto
distinto del sistema.

Leccin 6. Modelos UML

Los modelos de UML que se estudiaran en esta parte son los siguientes:

Diagramas de clases
Diagramas de Objetos
Diagrama de Actividades
Diagrama de Componentes
Diagrama de Despliegue
Diagrama de Casos de Uso
Diagrama de Secuencia
Diagrama de Colaboracin
Diagrama de Estados

Diagramas de clases: muestra un conjunto de clases, interfaces y colaboraciones,
as como sus relaciones, son los ms comunes en el modelo orientado a objetos y
cubren las vistas de diseo esttico de un sistema.

Diagramas de Objetos: muestra un conjunto de objetos y sus relaciones,
representan instancias de los elementos encontrados en los diagramas de clases,
representado cubren las vistas de diseo esttico de un sistema desde la perspectiva de
casos reales.

Diagrama de Actividades: es un tipo especial de diagrama de estados que
muestra el flujo de actividades dentro de un sistema, cubren la vista dinmica de un
sistema. Son especialmente importantes al modelar el funcionamiento de un sistema y
resaltan el flujo de control de objetos.

Diagrama de Componentes: muestra la organizacin y las dependencias
entre un conjunto de componentes, cubren la vista esttica de un sistema.

Diagrama de Despliegue: muestra la configuracin de nodos de
procesamiento en tiempo de ejecucin y los componentes que residen en ellos, cubren
la vista de despliegue esttica de una arquitectura.

Diagrama de Casos de Uso: muestra un conjunto de casos de uso, actores y
relaciones, cubren la vista de casos de uso esttica de un sistema.
Diagrama de Secuencia: es un diagrama de interaccin que resalta la ordenacin

18
temporal de los mensajes.

Diagrama de Colaboracin: es un diagrama de interaccin que resalta la
organizacin estructural de los objetos que envan y reciben mensaje.

Diagrama de Estados: Muestra una mquina de estados, que consta de estados,
transiciones, eventos y actividades, cubren la vista dinmica de un sistema, resaltan el
comportamiento dirigido por eventos de un objeto.

Leccin 7. Notas y Dependencias

Notas
Una nota sirve para aadir cualquier tipo de comentario a un diagrama o a un
elemento de un diagrama. Es un modo de indicar informacin en un formato libre,
cuando la notacin del diagrama en cuestin, nos permite expresar dicha informacin
de manera adecuada. Una nota se representa como un rectngulo con una esquina
doblada con texto en su interior. Puede aparecer en un diagrama tanto solo como unido
a un elemento por medio de una lnea discontinua. Puede contener restricciones,
comentarios, el cuerpo de un procedimiento, etc.

Figura 3: Nota

Dependencias
La relacin de dependencia entre dos elementos de un diagrama significa que un
cambio en el elemento destino puede implicar un cambio en el elemento origen (por
tanto, si cambia el elemento destino habra que revisar el elemento origen). Una
dependencia se representa por medio de una lnea de trazo discontinuo entre los dos
elementos con una flecha en su extremo. El elemento dependiente es el origen de la
flecha y el elemento del que depende es el destino (junto a l est la flecha).


19
Leccin 8. Elementos comunes a todos los diagramas

Un elemento es considerado como una abstraccin y dichos elementes se
clasifican en estructurales, de comportamiento, de agrupacin y de anotacin. En esta
leccin daremos una descripcin general, ya que a medida que se profundice en el
contenido del mdulo se dar respuesta a cada uno de los trminos de relaciones a este
espacio.

Figura 4: Elementos

Elementos de agrupamiento: Se realiza mediante el elemento de agrupacin
denominado paquete, es presentada por una caja que dentro de esta se puede se
descompuesto un modelo. Tambin aparecen los Frameworks, modelos y subsistemas
como a variaciones o tipos de paquetes.

Elementos estructurales: Es hace referencia a la parte esttica de un modelo,
representando elementos conceptuales o fsicos. Son siete los tipos de elementos
estructurales que son: Clase, Interfaz, Colaboracin, Caso de uso, clase activa,
componente, y nodo. Es importante tener muy claro que los nodos y componentes
representan elementos fsicos.

20

Al igual que los elementos de agrupacin en estos elementos tampoco
encontramos con variaciones a los siete elementos mencionados que se identifican
como: Tipos de clase: actores, seales, utilidades, Tipos de clases activas: procesos e
hilos y Tipos de Componentes: aplicaciones, documentos, archivos, bibliotecas,
pginas y tablas.

Elementos de comportamiento: Es la parte dinmica de un modelo y se ve
representada por los verbos que representan una funcin sobre tiempo y espacio.
Se identifican dos tipos de elementos de comportamiento: la interaccin y la
mquina de estado.

Elementos anotacin: Son los comentarios explcitos o muy detallados de un
modelo UML y se aplican para describir, iluminar y remarcar algunos elementos del
modelo. Solo presenta un tipo de elemento de anotacin que es denominado Nota y
este re registraran los comentarios y limitaciones asociados a un elemento o una
coleccin de datos.

Leccin 9. Fases de Desarrollo

Partamos identificando que un modelo es la representacin simple de la realidad,
estas fases se asemejan al ciclo de vida del desarrollo de software.

Figura 5: Fases de Desarrollo de un Sistema Soportado por UML

21

Anlisis: es donde se lleva el lenguaje natural a un lenguaje tcnico que es
fcilmente interpretado por desarrollador de un sistema.

Diseo: es la forma en la que se muestra la forma en la que se debe construir un
sistema para dar cumplimiento a unos requerimientos de un cliente o usuario. De un
buen diseo depende el resultado de un sistema.

Programacin: son todas las actividades necesarias para transformar los
requerimientos de un usuario plasmado en un diseo y convertido en un sistema de
software.

Prueba: es la parte donde se verifica, valida y se evidencia la calidad del producto
o sistemas de software desarrollado.

Anlisis de Requerimiento: es la fase donde el propsito fundamental es dejar
muy claro cules son las necesidades del usuario y los requerimientos.

Leccin 10. Herramientas Para Modelado

El kit ms importante en cuanto a herramientas prcticas y fciles de conseguir
son: papel, lpiz, borrador y saca punta, para realizar un diseo UML. Puede sonar raro
cuando estamos hablando de software y tecnologa pero estos materiales son
formidables para realizar diferentes tipos de diseo, en cualquier rea.

En esta leccin no se entrara a detallar herramientas o aplicaciones ya que esta
funcin la realizar diversos sitios web y los sitios principales de cada herramienta a los
cuales les corresponden convencer a los futuros ingenieros.

A continuacin se relacionarn varias herramientas de modelado gratuito, esto no
significa que son necesariamente software libre y quedarn muchsimas sin descubrir o
recomendar que pudieran ser mejores, pero esto depende de la autonoma de cada uno
de los diseadores y tambin de los recursos econmicos en el caso de que se requiera
obtener una licencia. Las recomendaciones que se registran a continuacin son tomadas
de la pgina http://www.rfsdigital.com/2012/01/herramientas-para-modelado-uml.html

1. ArgoUML (Clic para que acceda a la pgina principal de la aplicacin)


22

Figura 6: ArgoUML Editor UML

ArgoUML es un editor UML gratuito que tiene compatibilidad con el estndar UML
1.4. Permite la exportacin a varios formatos grficos y tiene la disponibilidad de perfiles
para varios lenguajes de programacin. Es mi herramienta favorita, aunque solo tiene
soporte para UML 1.4 (la ltima versin de UML es 2.4.1).

Al ser programado en Java, ArgoUML tiene la caracterstica de ser
multiplataforma. Entre sus caractersticas resalta lo siguiente:

Exportacin de diagramas a diferentes formatos
Generacin de cdigo
Soporte para bases de datos
Soporte cognitivo:

23
Crticas de diseo creado, listas de cosas por hacer (To Do Lists),
correcciones automticas, entre otros.
Comprensin y solucin del problema

2. Da (Clic para que acceda a la pgina principal de la aplicacin)

Figura 7: Da Editor de UML

Da es un programa de creacin de diagramas, similar al programa Visio de la
suite de ofimtica de Microsoft Office. Est basado en GTK+, biblioteca con objetos y
funciones para la interfaz grfica de usuario, y tiene licencia GPL. Dispone de una gran
serie de extensiones que permiten la elaboracin de diagramas entidad-interrelacin,
UML, flujo de datos, diagramas de red, entre otros.

3. Frame UML (Clic para que acceda a la pgina principal de la aplicacin)

Herramienta gratuita UML de fcil uso con soporte para UML 2, est pensado

24
para funcionar sobre Windows. Permite la generacin de cdigo desde el modelo. Tiene
soporte para 12 tipos de diagramas, excepto diagramas de objetos.

4. StarUML (Clic para que acceda a la pgina principal de la aplicacin)

StarUML es una herramienta de fcil uso que ayuda a generar diagramas
compatibles con la suite de ofimtica de Microsoft Office. Tiene cdigo es compatible con
C++ y Java. Y se puede empezar a dibujar manualmente o hacer uso de plantillas que
contienen archivos de instalacin, para modificarlas pensado en las persona que no
estn acostumbrada o que no hayan trabajado con anterioridad en modelamiento UML.

5. Tiny UML (Clic para que acceda a la pgina principal de la aplicacin)

TinyUML es una herramienta gratuita de modelado UML de fcil uso y de rpida
creacin de diagramas UML 2 implementado en la plataforma Java, requiere Java SE 6.

6. Eclipse (Clic para que acceda a la pgina principal de la aplicacin)

La aplicacin de eclipse no funciona como una herramienta directa de UML, sino
que requiere una extensin para realizar el modelado, adems que facilita que los
diagramas que se realicen en dicha herramienta se conviertan en cdigo.

Se recomienda descargar las siguientes extensiones para ser aplicada al eclipse y
poder realizar el diseo en este programa.

UML2
UML2 Tools

Seleccione la herramienta segn se ajuste a sus requerimientos y considere que
la ms fcil manejar y a medida que su nivel prctico y de conocimiento en el manejo del
lenguaje de modelado le permita escoger la herramienta ms avanzada. Es importante
entender que hay herramientas muy buenas, pero no necesariamente significa que ser
la que el diseador utilice, ya que puede considerar la herramienta menos conocida pero
que le arroje excelentes resultados y el nivel de manejo sea cmodo. Se recomienda
Eclipse y StarUML, pero sintase libre de tomar la mejor decisin que usted considere.

Es muy posible que se trabaje con una sola aplicacin para dar cumplimiento a un
desarrollo acadmico, que se dar a conocer directamente en el espacio donde se
considere necesario.

CAPITULO 3. MODELADO ESTRUCTURADO

Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje y
esto requiere aprender tres elementos principales: los bloques bsicos de construccin

25
de UML, las reglas que dictan cmo se pueden combinar estos bloques bsicos y
algunos mecanismos comunes que se aplican a travs de UML. Una vez comprendidas
estas ideas, se pueden leer los modelos UML y crear algunos modelos bsicos.

Leccin 11. Bloques de Construccin de UML
El vocabulario de UML incluye tres clases de bloques de construccin

Elementos en UML
Hay 4 tipos de elementos en UML, elementos estructurales, elementos de
comportamiento, elementos de agrupacin y elementos de anotacin:

Figura 8: Elementos UML

26
Elementos Estructurales

Nombre Descripcin Smbolo
Interfaz
Es una coleccin de operaciones que
especifica un servicio de una clase o componente,
representa el comportamiento completo de una
clase o componente

Colaboracin
Se definen como una interaccin y es una
sociedad de roles y otros elementos que
colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de los
comportamientos de sus elementos las colaboracin
representan la implementacin de
patronesque forman un sistema.

Caso de Uso
Es una descripcin de secuencias de
acciones que un sistema ejecuta y que produce un
resultado observable de inters para un actor
particular.
Se utiliza para estructurar el
comportamiento en un modelo

Clase Activa
Es un clase objetos tienen uno o mas
procesos o hilos de ejecucin y por lo tanto pueden
dar origen a actividades de control.
Son iguales a las clases excepto en que
sus objetos representan elementos cuyos
comportamiento es concurrente con otros elementos.

Componente
Es una parte fsica y reemplazable de un
sistema que conforma con un conjunto de interfaces
y proporciona la implementacin de dicho conjunto

Representa tpicamente e
empaquetamiento fsico de diferentes elementos
lgicos, como clases interfaces y
colaboraciones

Nodo
Es un elemento fsico que existe en tiempo
de ejecucin y representa un recursos
computacional que dispone de memoria y con
frecuencia capacidad de procesamiento
Nodo1


27
Estos siete elementos (clases, interfaces, colaboraciones, casos de uso, clases
activas, componentes y nodos) son los elementos estructurales bsicos que se pueden
incluir en el modelo UML. Tambin existen variaciones de estos siete elementos, tales
como actores, seales, procesos, hilos y aplicaciones, documentos, archivos,
bibliotecas, pginas y tablas.

Los elementos de comportamiento: son las partes dinmicas de los modelos
UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y
en el espacio.

Interaccin: e s un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular
para alcanzar un propsito especifico

Mquina de Estados: es un comportamiento que especifica las secuencias de
estados por las que pasa un objeto o una interaccin durante su vida en respuesta a
eventos

Estos dos elementos (interacciones y mquinas de estado) son los elementos de
comportamiento que se pueden incluir de un modelo UML, estos elementos estn
conectados normalmente a diversos elementos estructurales, principalmente clases,
colaboraciones y objetos.

Los Elementos de agrupacin: son las partes organizativas de los modelos UML.
Estos son las cajas en las que pueden descomponerse un modelo

Paquete: es un mecanismo de propsito general para organizar elementos en
grupos.

En los paquetes se pueden agrupar los elementos estructurales, de
comportamiento e incluso otros elementos de agrupacin

Los paquetes son los elementos de agrupacin bsicos con los cuales se puede
organizar un modelo UML. Tambin hay variaciones, tales como los framework, los
modelos y los subsistemas.

Relaciones: Existen cuatro tipos de la relaciones en UML
Dependencias
Asociaciones
Generalizaciones
Realizacin

Estas relaciones son los bloques bsicos de construccin para las relaciones
de UML.


28
Relaciones en UML

Dependencia: es una relacin semntica entre dos elementos, en la cual un
cambio a un elemento puede afectar el significado de otro elemento.

Asociaciones: es una relacin estructural que describe un conjunto de enlaces,
los cuales son conexiones entre objeto y representan una relacin estructural entre un
todo y sus partes.

Diagramas: un diagrama es la representacin grfica de un conjunto de
elementos, visualizando la mayora de las veces como un grafo conexo de nodos
(elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema
desde diferentes perspectivas, de forma que un diagrama es una proyeccin de
un sistema, un diagrama representa una vista resumida de los elementos que
constituyen un sistema. (Los tipos de diagramas que utiliza UML se mencionan en el
Numeral 1.1.2. de este mdulo).

Clases: una clase es una descripcin de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y semntica. Las clases
pueden representar cosas como hardware, software o solo conceptuales y tambin
forman parte de una distribucin equilibrada de responsabilidades en el sistema

UML representa una representacin grfica de las clases como se muestra en la
figura.

Figura 9: Clases

Componentes de las Clases

Una clase es una descripcin de un conjunto de objetos que comparten los
mi mos atributos, operaciones, relaciones y semnticas. Grficamente una clase se
representa como un rectngulo, en el cual se describen las caractersticas de los
objetos que representa, entre ellos tenemos.


29
1. Nombre: una clase debe contener un nombre que la identifique, compuesto por
cualquier nmero de letras y nmeros exceptuando los dos puntos pues estos se
utilizan para separar el nombre de una clase y el paquete que lo contiene.

2. Atributos: es una propiedad de una clase identificada con un nombre,
que describe un rango de valores que pueden tomar las instancias de la propiedad. Un
atributo representa alguna propiedad del elemento que se est modelando que es
compartida por todos los objetos de esa clase, adems, una clase puede o no contener
atributos. Por ejemplo un atributo de la clase estudiante es el nombre, apellido, fecha
Nacimiento, etc.

3. Operaciones: es una abstraccin de algo que puede hacer un objeto y que es
compartido por todos los objetos de la clase. Las clases pueden tener o no operaciones.
Ejemplo: La clase estudiante puede tener los objetos generados por ella: matricular,
evaluar, aprobar y estas operaciones son comunes a todos los objetos que se describen
a travs de la clase estudiante.

Figura 11: Operaciones

4. Responsabilidades: Al crear una clase, se est expresando que todos los
objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento.
De forma ms general los atributos y operaciones son las caractersticas por medio de
la cuales se llevan a cabo las responsabilidades de la clase. Grficamente las
responsabilidades se pueden expresar en un comportamiento separado al final del icono
de la clase.

Figura 10: Atributos

30

Figura 12: Responsabilidades
Usos Comunes de las Clases

Las clases se utilizan para modelar y representar el conjunto de elementos de un
sistema de manera general (abstracciones), para determinar los problemas que se
intenta resolver y as implementar una solucin.

Para definir las clases que intervienen dentro de un sistema se recomienda como
puntos de partida las siguientes consideraciones:
Identificar aquellas cosas que utilizan los usuarios o programadores
para describir el problema o la solucin.
Identificar las responsabilidades de cada clase y asegurarse que cada
clase existe.
Identificar los atributos y operaciones necesarios para cumplir
sus responsabilidades.
Hacer del conjunto de clases y sus responsabilidades un modelo
equilibrado donde no existan clase demasiado grandes ni pequeas
Cuando se dibuje una clase hay que mostrar solo aquellas propiedades de
la clase que sean importantes, como tambin sus atributos y operaciones

Objetos

Un objeto se representa de la misma forma que una clase. En el compartimiento
superior aparecen el nombre del objeto junto con el nombre de la clase
subrayados, segn la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase
Puede representarse un objeto sin un nombre especfico, entonces slo aparece el
nombre de la clase.


31

Figura 13: Objetos
Asociaciones

Es una relacin estructural que especifica que los objetos de un elemento estn
conectados con los objetos de otro. Dada una asociacin entre dos clases, se puede
navegar desde un objeto de una clase hasta el objeto de otra clase, y viceversa. Una
asociacin que conecta dos clases se dice binaria, s conecta ms de dos clases se
denomina asociacin n-arias, las asociaciones se utilizarn cuando se quieren
representar relaciones estructurales.

Caractersticas de las Asociaciones y operaciones

Nombre de la Asociacin y Direccin

El nombre de la asociacin se utiliza para describir la naturaleza de la relacin,
es opcional y se muestra como un texto que est prximo a la lnea. Se puede aadir un
pequeo tringulo negro slido que indique la direccin y permita leer el nombre de
la asociacin. En el ejemplo se puede leer la asociacin como Director manda sobre
Empleado.

Figura 14: Asociacin
Los nombres de las asociaciones normalmente se incluyen en los modelos para
aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado
abundante la informacin que se presenta, con el consiguiente riesgo de saturacin. En
ese caso se puede suprimir el nombre de las asociaciones consideradas como
suficientemente conocidas. En las asociaciones de tipo agregacin y de herencia no se
suele poner el nombre.

32
Multiplicidad

La multiplicidad es una restriccin que se pone a una asociacin, que limita el
nmero de instancias de una clase que pueden tener esa asociacin con una instancia
de la otra clase. Puede expresarse de las siguientes formas:

Con un nmero fijo: 1.
Con un intervalo de valores: 2.5.
Con un rango en el cual uno de los extremos es un asterisco Significa
que es un intervalo abierto. Por ejemplo, 2..* significa 2 o ms.
Con una combinacin de elementos como los anteriores separados por
comas: 1, 3..5, 7, 15..*.
Con un asterisco: * . En este caso indica que puede tomar cualquier valor
(cero o ms).

Roles
Un rol es simplemente la cara que la clase de un extremo de la
asociacin presenta a la clase del otro extremo.

Figura 15: Roles
Para indicar el papel que juega una clase en una asociacin se puede especificar
un nombre de rol. Se representa en el extremo de la asociacin junto a la clase que
desempea dicho rol.


33
Agregacin
El smbolo de agregacin es un diamante colocado en el extremo en el que est
la clase que representa el todo.

Figura 16: Agregacin

Leccin 12. Diagramas

Un diagrama es una presentacin grfica de un conjunto de elementos, que la
mayora de las veces se dibuja como un conjunto de elementos relacionados. Los
diagramas se utilizan para representar un sistema desde diferentes perspectivas, por
esto UML ha definido varios diagramas que permiten centrarse en diferentes aspectos
del sistema de manera independiente.

Un diagrama es una proyeccin grfica de los elementos que configuran un
sistema. Por ejemplo, se podra tener cientos de clases en el diseo de un sistema de
recursos humanos de un empresa, pero no se podra ver la estructura o el
comportamiento de ese sistema observando un gran diagrama con todas sus clases y
relaciones, es entonces preferible realizar varios diagramas que especifiquen las vistas
relevantes solamente a ese subsistema definido, este tipo de manejo de diagramas
representativos por clases permite realizar agrupaciones que muestran el
funcionamiento general del sistema de forma particular pero denotando el
funcionamiento general del sistema con todos sus elementos constitutivos.

Con el modelado de sistemas se obtienen deferentes tipos de vistas, las vistas
estticas de los sistemas en UML se representan con 4 tipos de diagramas que se
describen a continuacin
Diagramas Estructurales
Los cuales comprenden los siguientes diagramas
Diagramas de Clases
Representa un conjunto de clases, interfaces y colaboraciones, y las relaciones
entre ellas. Los diagramas de clases los diagramas ms comunes en el modelado de
sistemas orientados a objetos. Estos diagramas se utilizan para describir las vista de
diseo esttica de un sistema, incluyen clases activas se utilizan para cubrir la vista de
procesos esttica de un sistema

34
Diagramas de Objetos
Representa un conjunto de objetos y sus relaciones. Se utiliza para describir
estructuras de datos y las instancias de los elementos encontrados en los diagramas de
clases. Cubren la vista de diseo esttica o la vista de proceso esttica de un sistema
al igual que los diagramas de clases. Pero desde la perspectiva de casos reales
prototipos.

Diagramas de Componentes
Muestra un conjunto de componentes y relaciones, se utilizan para describir
la vista de implementacin esttica de un sistema, se relacionan con los diagramas de
clases en que un componente normalmente se corresponde con una o ms clases.
Interfaces o colaboraciones

Diagramas de despliegue
Muestra un conjunto de nodos y sus relaciones, se utilizan para describir la
vista de despliegue esttica de una arquitectura, se relacionan con los diagramas de
componentes en que un nodo normalmente incluye uno o ms componentes.

Diagramas de Comportamiento
Los cuales estn compuestos por los siguientes diagramas

Diagramas de casos de uso
En el modelado orientado a objetos los diagramas de casos de uso, son los que
representan en general el funcionamiento del sistema siendo estos los ms utilizados
como base del desarrollo de un modelo real, representan casos de uso, actores y
relaciones, se utilizan especialmente para organizar y modelar el comportamiento de un
sistema.

Diagramas de Secuencia
Es un diagrama de interaccin que resalta la ordenacin temporal de los
mensajes, este presenta un conjunto de objetos y los mensajes enviados por ellos. Los
objetos suelen ser instancias con nombre, pueden representar instancias de otros
elementos, tales como colaboraciones, componentes y nodos, se utilizan para
describir la vista dinmica de un sistema.

Diagramas de colaboracin
Son diagramas de interaccin que resalta la organizacin estructural de los
objetos que envan y reciben mensajes, pueden representar instancias de otros
elementos como colaboraciones, componentes y nodos. Se utilizan para describir la
vista dinmica de un sistema.


35
Diagramas de estado
Representan una mquina de estados constituida por estados, transacciones,
eventos y actividades, se utilizan para representar la vista dinmica de un sistema son
especialmente importantes para modelar el comportamiento de una interfaz, clase o una
colaboracin, resaltan en comportamiento dirigido por eventos de un objeto.

Diagrama de Actividades
Muestra el flujo de actividades en un sistema, muestra el flujo secuencial o
ramificado de actividades y los objetos en los que acta, son importantes para
modelar la funcin de un sistema as como para resaltar el flujo de control entre objetos

Leccin 13. Diagramas de Clase

Un diagrama de clases de uso muestra un conjunto de interfaces,
colaboraciones y sus relaciones. Grficamente, un diagrama de clases es una coleccin
de nodos y arcos.

Los diagramas de clases contienen normalmente los siguientes elementos,
clases, interfaces, colaboraciones, relaciones de dependencia, generalizacin y
asociacin. Los diagramas pueden tambin notas, restricciones, paquetes o
subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes
ms grandes.

Usos de los diagramas de clases
Se utilizan para modelar la vista esttica de un sistema, muestra
principalmente los requisitos funcionales de un sistema y los servicios que el sistema
debe proporcionar a sus usuarios finales

Los diagramas de clases se utilizan cuando se modela la vista de diseo de un
sistema de la siguiente forma:

Para modelar el vocabulario de un sistema
El modelado del vocabulario de un sistema implica tomar decisiones sobre que
abstracciones son parte del sistema en consideracin y cuales caen fuera de sus
lmites. Los diagramas de clases se utilizan para especificar estas abstracciones y sus
responsabilidades

Para modelar colaboraciones simples
Una colaboracin es una sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar un comportamiento cooperativo mayor que la suma de
todos los elementos.

36
Cuando se crea un diagrama de clases, se est modelando una parte de los
elementos y las relaciones que configuran la vista de diseo del sistema, por esta
razn, cada diagrama de clases debe centrarse en una colaboracin cada vez. Para
modelar una colaboracin se debe tener en cuenta:

Identificar los mecanismos que se quiere modelar, un mecanismo
representa una funcin o comportamiento de la parte del sistema que se
est modelando que resulta de la interaccin de una sociedad de clases,
interfaces y otros elementos.
Identificar las clases, interfaces y otras colaboraciones que participan en
esta colaboracin identificando las relaciones entre estos elementos.
Usar escenarios para recorrer la interaccin entre estos elementos.
Identificar las responsabilidades y hacer un reparto equilibrada de ellas en
los elementos que componen el sistema.

Por ejemplo la siguiente figura muestra un conjunto de clases que muestran el
sistema de facturacin y control de ventas de una empresa, las clases se centran en la
forma como se maneja la facturacin de inmuebles y productos de consumo. Aparece
una clase abstracta llamada factura que muestra a su vez 2 hijos factura comestibles y
factura inmuebles a su vez las dos clases se muestran como partes de otra clase
denominada vendedor. La clase ventas tiene una asociacin uno a uno con vendedor y
una asociacin uno a muchos con controlvendedor. No se muestran atributos ni
operaciones para la clase ventas, pero s se muestran sus responsabilidades.

Figura 17: Conjunto de Clases

Para modelar un esquema lgico de base de datos

Este esquema representa el plano que permite el diseo conceptual de la base de

37
datos sea para una base de datos relacional o una base de datos orientada a objetos.
Para modelar un esquema tenemos en cuenta:

Identificar las clases que van a ser persistentes en el diseo general de la
bases de datos.
Crear un diagrama de clases que contenga estas clases y marcarlas como
persistentes.
Expandir los detalles estructurales de estas clases, es decir, especificar los
detalles de sus atributos y centrar su atencin en las asociaciones que
estructuran estas clases.
Identificar las relaciones de las bases de datos sea uno a uno, uno a varios
y sus asociaciones.
Definir de manera clara las reglas de negocio relativas a la manipulacin
de datos dentro de la base de datos

La figura muestra un conjunto de clases extradas de un sistema de informacin
que determina las relaciones entre los estudiantes, el profesor y el curso que el
estudiante va a estudiar

Figura 18: Conjunto de Clases Extradas de un Sistema de Informacin

El anterior diagrama muestra en detalle cada una de las clases con sus
respectivos atributos, los cuales permiten construir la base de datos fsica, comenzando
por la parte inferior izquierda se encuentra las clases estudiantes, curso y profesores,
hay una asociacin.

38
Las clases se han marcado como persistentes, es decir, sus instancias se han
concebido para almacenar en una base de datos u otra forma de almacenamiento
persistente.

Leccin 14. Caractersticas avanzadas de las clases y relaciones

El tipo ms importante de clasificador en UML es la clase, una clase es una
descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica. Sin embargo, las clases no son el nico tipo de
clasificador, existen otros tipos de clasificadores que ayudan a modelar:

Interfaz: es una coleccin de operaciones que especifican un servicio de
una clase o componente

Figura 19: Interfaz

Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los
tipos primitivos predefinidos.

Figura 20: Tipos de Datos

Seal: la especificacin de un estmulo asncrono enviado entre instancias

Figura 21: Seal

Componente: una parte fsica y reemplazable de un sistema que conforma
y proporciona la realizacin de un conjunto de interfaces.

Figura 22: Componente
Nodo: un elemento fsico que existe en tiempo de ejecucin y representa

39
un recurso computacional, generalmente con alguna memoria y a menudo
capacidad de almacenamiento.

Figura 23: Nodo

Caso de uso: descripcin de una secuencia de acciones, incluye variantes,
que se ejecuta un sistema y produce un resultado observable para un actor
particular

Figura 24: Caso de Uso

Subsistema: agrupacin de elementos, algunos de los cuales constituyen
una especificacin del comportamiento de los otros elementos contenidos

Figura 25: Subsistema

Los clasificadores descritos anteriormente proporcionan al modelado de sistemas
una vista general de comportamiento del sistema mostrndolo en detalle en sus atributos
y operaciones

Generalidades de las clases

Es necesario saber que para el modelado de sistemas con UML, las clases
muestran en la definicin de sus atributos ciertos tipos de smbolos, los cuales
determinan si los elementos asociados a cada clase son pblicos o privados por
ejemplo:

Si la marca de elemento es un +, indica que este elemento es de acceso pblico
y por lo tanto se pueden operar desde cualquier instancia del sistema. Por el contrario,
si el signo es -, indica que este elemento solo es de uso exclusivo de la clase que lo
contiene. Otro caso en los cuales los elementos de la clase son por decirlo de alguna

40
semi privados, solo se relacionan con las clases que han sido descendientes de la clase
padre y estas se marcan con el smbolo #.

Cuando se usa una clase, es probable que se deseen caractersticas de
otras clases y tambin permitir que otras clases ms especficas hereden caractersticas
de ella. Tambin se puede especificar que una clase no puede tener hijos, a este
elemento se le llama hoja y se especifica escribiendo la propiedad leaf bajo el nombre
de la clase. Otra caracterstica de las clases, es cuando esta no tiene padres, este tipo
de clases se denomina raz y se denota escribiendo debajo del nombre de la clase root.

Podemos observar el siguiente ejemplo de notacin:

Figura 26: Notacin

Las clases tienen muchas operaciones entre s, las que se heredan entre clases
se denominan polimrficas esto ocurre cuando los objetos han ejecutado una operacin
que est definida en la clase que los contiene pero con la diferencia de que la
operacin cambia de significado dependiendo del contexto donde se est ejecutado.

Generalidades de las relaciones

Al modelar los elementos que constituyen el vocabulario de un sistema, tambin
hay que modelar cmo se relacionan entre s estos elementos, las relaciones de
dependencia, las generalizaciones y las asociaciones son los tres bloques de
construccin de relaciones ms importantes de UML. Observemos el comportamiento de
estas relaciones.

41
Relaciones de Dependencia:

Una dependencia es una relacin de uso, la cual especifica que un cambio en la
especificacin de un elemento puede afectar a otro elemento que lo utiliza, pero no
necesariamente a la inversa. Grficamente, una dependencia se representa como una
lnea continua dirigida hacia el elemento del que se depende. Las dependencias se
deben aplicar cuando se quiera representar que un elemento utiliza a otro

Relaciones de Generalizacin

Una generalizacin es una relacin entre un elemento (superclase o padre) y un
tipo ms efectivo de ese elemento (subclase o hijo). Por ejemplo, se puede encontrar la
clase general ventana junto a un tipo ms especfico ventaconmarco, con una relacin
de generalizacin del hijo al padre, el hijo ventaconmarco heredar la estructura y
comportamiento del padre ventana, en una generalizacin la instancia del hijo pueden
usarse donde quiera que se puedan usar las instancias del padre.

La generalizacin se manifiesta en la herencia simple que a veces es suficiente
en la mayora de las veces, aunque, la herencia mltiple es ms adecuada,
grficamente se muestra de la siguiente forma:

Figura 27: Herencia Mltiple

En la figura anterior se muestra la clase activo con tres hijos: CuentaBancaria,
inmueble y valor dos de estos hijos (CuentaBancaria, Inmueble) tienen sus
propios hijos por ejemplo Accin y Bono son ambos hijos de valor

Dos de estos hijos (CuentaBancaria, Inmueble) heredan de varios
padres. inmueble por ejemplo, es un tipo de activo, as como un tipo de
Elemento-Asegurable y CuentaBancaria, es un tipo de activo as como
un ElementoConInteres y un ElementoAsegurable


42

Relaciones de Asociacin

Una asociacin es una relacin estructural que especifica que los objetos de un
elemento se conectan a los objetos de otro, por ejemplo, una clase biblioteca
podra tener una asociacin uno a muchos con clase libro, indicando que cada instancia
de libro pertenece a una instancia de biblioteca, adems, dado un libro, se puede
encontrar su biblioteca, y dando una biblioteca se puede navegar hacia todos los libros,
grficamente, un asociaciones se representa con una lnea continua entre la misma o
diferentes clases. Las relaciones se utilizan para mostrar relaciones estructurales.

En la siguiente asociacin simple se muestra como se hace la navegacin entre
objetos, por ejemplo al modelar una asociacin entre 2 objetos como Usuario y Clave se
tiene que un dado un Usuario se puede encontrar las correspondientes Claves, pero
dada una Clave no se podra identificar al Usuario correspondiente.

Figura 28: Asociacin

La lnea representa una asociacin y la fecha indica la direccin del recorrido

Interfaces, Tipos y roles

Interfaz

El manejo de las interfaces dentro del UML es importante ya que proporcionan al
modelador un registro exacto de las fronteras existentes entre los diferentes procesos
del sistema, con lo cual se pretende observar al sistema en sus componentes integrales
para as determinar que procesos se pueden afectar sin que se afecten los otros.

La construccin de interfaces permite tambin el manejo de libreras estndar
reutilizables sin tener que construirlas nuevamente, permitiendo reemplazos sin
necesidad de afectar el funcionamiento general del sistema. Se entiendo como interfaz
como una coleccin de operaciones que sirven para especificar un servicio de una clase
o un componente.

Cada interfaz ha de tener un nombre que la distingue de otras interfaces,
el nombre de la interfaz puede ser simple o de camino cuando en este se indica el
nombre de la interfaz y el paquete en el que se encuentre.


43

Figura 29: Interfaces

Operaciones de las Interfaces

Al contrario de las clases y los tipos, las interfaces no especifican ninguna
estructura, las interfaces no incluyen atributos ni mtodos, pero estas pueden contener
cualquier nmero de operaciones. La siguiente notacin hace referencia a una interfaz
donde se manifiesta de manera grfica su nombre y operaciones a diferencia de la
notacin del crculo presentada anteriormente.

Proporciona un mecanismo para modelar la conformidad esttica y dinmica de
una abstraccin con una interfaz en un contexto especfico

Figura 30: Abstraccin con una Interfaz

Ntese en la representacin el nombre <<interface>> como identificador de
la interface definida.

Las relaciones entre interfaces se realizan de la misma manera como se
relacionan con las clases puesto que las relaciones son del mismo tipo, para recordar:
relaciones de generalizacin, relaciones de asociacin y relaciones de dependencia.

Como se mostr anteriormente las interfaces se pueden denotar mostrndose
como un crculo o con sus operaciones, dentro de un diagrama de interaccin entre
clases los resultados para mostrar las relaciones entre las clases a travs de las
interfaces se expresa de la siguiente manera:


44

Figura 31: Diagrama de Interaccin entre Clases

La primera forma es la sencilla en la cual se muestra la conexin de dos clases a
travs de un circulo que representa la interfaz con la cual se comunican dichas clases,
la segunda forma, muestra de manera ms detallada las operaciones con las cuales
interactan las clases definidas antes y despus de la interface, ntese como se
representan las relaciones de dependencia de la misma forma como se mostr en las
relaciones entre clases.

Tipos y roles

Un rol representa un comportamiento de una entidad que participa en un contexto
particular, por ejemplo consideremos una instancia de una clase denominada profesor,
este profesor puede ser de matemticas, sociales, informtica, fsica, etc, para cada rol
generado de clase profesor, se deduce que las propiedades cada rol son exclusivas y
en ningn momento pueden tomar propiedades de un rol que no le corresponda.

Para representar el rol que representa un objeto dentro de una relacin de clases
en notacin UML se tiene por ejemplo:

Figura 32: Relacin de Clases en Notacin

45

Figura 33: Objeto Dentro Relacin de Clases en Notacin

La figura anterior representa una asociacin de clases con una interfaz especfica,
como se ve existe una asociacin de entre las clases persona y empresa en cuyo
contexto personal juega un rol llamado e, cuyo tipo es empleado

Paquetes e Instancias

Un paquete es un mecanismo de propsito general para organizar elementos en
grupos, grficamente un paquete se representa como una carpeta. Cada paquete a de
contener un nombre que lo distingue de los dems.

Figura 34: Elementos Contenidos en el Paquete

Un paquete puede contener otros elementos incluyendo clases, interfaces,
componentes, nodos, colaboraciones, casos de uso, diagramas en incluso otros
paquetes. S el paquete se destruye el elemento contenido en l es destruido, pues
cada elemento cada elemento pertenece exclusivamente a un nico paquete.

Una instancia es una manifestacin concreta de una abstraccin a la que se
puede aplicar un conjunto de operaciones y que posee un estado que almacena el
efecto de las operaciones. Grficamente una instancia se representa subrayando su
nombre.

46

Figura 35: Instancias

Las instancias no aparecen aisladas, casi siempre estn ligadas a
una abstraccin. La mayora de las instancias que se modelan en UML sern
instancias de clases (llamadas objetos), aunque se pueden tener instancias de otros
elementos, como componentes, nodos, casos de usos y asociaciones.

En sentido general, un objeto es algo que ocupa espacio en el mundo real o
conceptual y al que se le pueden hacer cosas. Por ejemplo, una instancia de un nodo es
normalmente un computador que se encuentra fsicamente en una habitacin; una
instancia de un componente ocupa algo de espacio en el sistema de archivos; una
instancia de un registro de un cliente consume algo de memoria fsica, anlogamente,
una instancia de un billete de avin es algo sobre lo que se pueden hacer clculos.

Leccin 15. Herencia y polimorfismo

Polimorfismo

Una de las caractersticas fundamentales de la OOP es el polimorfismo, que no
es otra cosa que la posibilidad de construir varios mtodos con el mismo nombre,
pero con relacin a la clase a la que pertenece cada uno, con comportamientos
diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases
diferentes. Estos objetos recibiran el mismo mensaje global pero responderan a l de
formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significara suma,
mientras que para un objeto STRING significara concatenacin ("pegar" strings uno
seguido al otro)

Herencia

En programacin orientada a objetos, la herencia es un mecanismo que hace
posible que una clase herede todo el comportamiento y atributos de otra clase; a travs
de la herencia, una clase tiene inmediatamente toda la funcionalidad de una clase
existente, debido a esto, las nuevas clases se pueden crear indicando nicamente

47
en que se diferencian de la clase existente, es decir, que toma la definicin previa de la
cual es subclase, y que solo se le agrega caractersticas especiales que la difieren de la
clase de la cual procede. La relacin de herencia se representa mediante un tringulo
en el extremo de la relacin que corresponde a la clase ms general o clase padre.

48

SEGUNDA UNIDAD

CARACTERSTICAS DEL MODELADO UML


49
UNIDAD 2. CARACTERSTICAS DEL MODELADO UML

CAPITULO 4. DIAGRAMAS UTILIZADOS EN UML

Leccin 16. Diagramas de Objetos

Los diagramas de objetos modelan las instancias de elementos contenidos en
los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y
sus relaciones en un momento concreto. En UML, los diagramas de clase se
utilizan para visualizar los aspectos estticos del sistema y los diagramas de
interaccin se utilizan para ver los aspectos dinmicos del sistema, y constan de
instancias de los elementos del diagrama de clases y mensajes enviados entre ellos.

En un punto intermedio podemos situar los diagramas de objetos, que
contiene un conjunto de instancias de los elementos encontrados en el diagrama de
clases, representando slo la parte esttica de una interaccin, consistiendo en los
objetos que colaboraran pero sin ninguno de los mensajes intercambiados entre
ellos.

Los diagramas de objetos se emplean para modelar la vista de diseo esttica o
la vista de procesos esttica de un sistema al igual que se hace con los diagramas de
clases, pero desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta
principalmente los requisitos funcionales de un sistema. Los diagramas de objetos
permiten modelar estructuras de datos estticas,

En general los diagramas de objetos se utilizan para modelar estructuras de
objetos, lo que implica tomar una instantnea de los objetos de un sistema en un cierto
momento. Un diagrama de objetos representa una escena esttica dentro de la historia
representada por un diagrama de interaccin. Los diagramas de objetos se utilizan para
visualizar, especificar, construir y documentar la existencia de ciertas instancias en el
sistema, junto a las relaciones entre ellas.

Figura 36: Diagrama de Objetos

50
En la figura anterior se representa un conjunto de objetos extrados de la
implementacin de un robot. Como indica la figura, un objeto representa al propio robot,
(r es una instancia de Robot), y r se encuentra actualmente en estado movi miento. Este
objeto tiene un enlace con m, una instancia de Mundo, que representa una abstraccin
del modelo del mundo del robot. Este objeto tiene un enlace con un multiobjeto, un
conjunto de instancias de Elemento, que representan entidades que el robot ha
identificado, pero an no ha asignado en su vista del mundo.

En este instante, m est enlazado a dos instancias de rea. Una de ellas (a2) se
muestra con sus propios enlaces a tres objetos Pared y un objeto Puerta. Cada una
de estas paredes est etiquetada con su anchura actual, y cada una se muestra
enlazada a sus paredes vecinas. Como sugiere este diagrama de objetos, el robot ha
reconocido el rea que lo contiene, que tiene paredes en tres lados y una puerta en el
cuarto.

Como vemos los diagramas de objetos son especialmente tiles para modelar
estructuras de datos complejas. Evidentemente puede existir una multitud de posibles
instancias de una clase particular, y para un conjunto de clases con t relaciones entre
ellas, pueden existir muchas ms configuraciones posibles de estos objetos. Por lo
tanto, al utilizar diagramas de objetos slo se pueden mostrar significativamente
conjuntos interesantes de objetos concretos o prototpicos.

Leccin 17. Diagramas de Casos de Uso

El diagrama de casos de uso representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los
elementos interactan (operaciones o casos de uso). Un diagrama de casos de uso
consta de los siguientes elementos:

Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor

Figura 37: Actor

51

Una definicin previa, es que un Actor es un rol que un usuario juega
con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto
se especifica que un Actor no necesariamente representa a una persona en particular,
sino ms bien la labor que realiza frente al sistema.

Como ejemplo a la definicin anterior, tenemos el caso de un sistema de
ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un
Vendedor o bien por el Jefe de Local.

Caso de Uso

Figura 38: Caso de Uso
Es una operacin o tarea especfica que se realiza tras una orden de algn
agente externo, sea desde una peticin de un actor o bien desde la invocacin desde
otro caso de uso.

Relaciones

Las relaciones se explicaron de manera especfica en el apartado 1.2.4 de este
mdulo, ahora se explica de manera sencilla para observar su uso dentro de los
diagramas de casos de uso.

Asociacin

Es el tipo de relacin ms bsica que indica la invocacin desde un actor o
caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha
simple.

Dependencia o Instanciacin

Es una forma muy particular de relacin entre clases, en la cual una
clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una
flecha punteada.

Generalizacin

Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia

52
(<<extends>>).

Este tipo de relacin est orientado exclusivamente para casos de uso (y no para
actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(caractersticas).

Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que
son similares en ms de un caso de uso y no se desea mantener copiada la descripcin
de la caracterstica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y
modelamiento de clases, en donde est la duda clsica de usar o heredar.

Ejemplo:

Como ejemplo est el caso de una Mquina Recicladora: Sistema que
controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe
controlar y/o aceptar lo siguiente:

Registrar el nmero de tems ingresados.
Imprimir un recibo cuando el usuario lo solicita:
Describe lo depositado
El valor de cada tem
Total
El usuario/cliente presiona el botn de comienzo
Existe un operador que desea saber lo siguiente:
Cuantos tems han sido retornados en el da.
Al final de cada da el operador solicita un resumen de todo lo
depositado en el da.
El operador debe adems poder cambiar:
Informacin asociada a tems.
Dar una alarma en el caso de que:
tem se atora.
No hay ms papel.

Como una primera aproximacin identificamos a los actores que interactan con
el sistema:


53

Figura 39: Los Actores que Interactan con el Sistema

Luego, tenemos que un Cliente puede Depositar tems y un Operador puede
cambiar la informacin de un tem o bien puede Imprimir un informe:

Figura 40: Cliente Puede Depositar tems y un Operador Puede Cambiar la Informacin de un tem o Bien
Puede Imprimir un Informe

Adems podemos notar que un tem puede ser una Botella, un Tarro o una Jaba.

Figura 41: Depositar tem


54
Otro aspecto es la impresin de comprobantes, que puede ser realizada despus
de depositar algn tem por un cliente o bien puede ser realizada a peticin de un
operador.

Figura 42: Peticin a un Operador
Entonces, el diseo completo del diagrama casos de uso es:

Figura 43: Diseo Completo del Diagrama de Casos de Uso
Leccin 18. Diagramas de Interaccin

Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de
un sistema, lo que conlleva modelar instancias concretas o prototpicas de clases
interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo
en el contexto de un escenario que ilustra un comportamiento. En el contexto de las
clases describen la forma en que grupos de objetos colaboran para proveer un
comportamiento.

En los diagramas de interaccin se muestra un patrn de interaccin entre
objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la misma
informacin, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia

55
y Diagramas de Colaboracin.

Leccin 19. Diagrama de Secuencia

Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia
temporal de eventos. En particular, muestra los objetos participantes en la interaccin y
los mensajes que intercambian ordenados segn su secuencia en el tiempo. El eje
vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores
participantes en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una
lnea vertical, y los mensajes se representan mediante flechas entre los distintos
objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como
restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o
bien junto a las transiciones o activaciones a las que se refieren.

Figura 44: Transiciones y Activaciones

56
Los diagramas de secuencia tienen 2 caractersticas que los distinguen de los
diagramas de colaboracin, en primer lugar est la lnea de vida de un objeto que es la
lnea discontinua vertical que representa la existencia de un objeto a lo largo de un
periodo de tiempo. La mayora de los objetos que aparecen en un diagrama de secuencia
existirn mientras dure la interaccin, los objetos se colocan en la parte superior del
diagrama con sus lneas de vida dibujadas de arriba hasta abajo. Pueden crearse
objetos durante la interaccin, sus lneas de vida comienzan con la recepcin de
mensajes estereotipado como crate. Los objetos pueden destruirse durante la
interaccin, sus lneas de vida acaban con la recepcin del mensaje estereotipado como
destroy, adems, se muestra la seal visual de una gran X que marca el final de sus
vidas.

Leccin 20. Diagrama de Colaboracin

Un diagrama de colaboracin destaca la organizacin de los objetos que
participan en una interaccin, un diagrama de colaboracin se construye colocando
en primer lugar los objetos que participan en la colaboracin como nodos de un grafo. A
continuacin se representa los enlaces que conectan esos objetos como arcos de
grafo, por ltimo, estos enlaces se adorna con los mensajes que envan y reciben
los objetos, esto da al lector una seal visual clara del flujo de control en el contexto de la
organizacin estructural de los objetos que colaboran

Figura 45: Flujo de Control

Los diagramas colaboracin tienen dos caractersticas que los distinguen de los
diagramas de secuencia, el primero para indicar cmo se enlaza un objeto a otro, se
puede asociar un objeto al extremo ms lejano de un enlace con la palabra local que
indica que el objeto designado es local al emisor. En segundo lugar est el nmero de
secuencia, para indicar la ordenacin temporal de los mensajes, se precede de un
nmero iniciando con el numeral 1, que se incrementa
secuencialmente por cada nuevo mensaje en el flujo de control.


57
Leccin 21. Diagramas de Actividades

Un diagrama de actividades muestra el flujo de actividades, siendo un actividad
una ejecucin general entre los objetos que se est ejecutando en un momento dado
dentro de una mquina de estados, el resultado de un actividad es una accin que
producen un cambio en el estado del sistema o la devolucin de un valor. Las acciones
incluyen llamadas a otras operaciones, envo de seales, creacin o destruccin de
objetos o simples clculos. Grficamente un diagrama de actividades ser un conjunto
de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades
muestra cmo fluye el control de unas clases a otras con la finalidad de culminar con un
flujo de control total que se corresponde con la consecucin de un proceso ms complejo.
Por este motivo, en un diagrama de actividades aparecern acciones y actividades
correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin.
Ejemplo: Hacer un pedido.

Contenido del diagrama de actividades

Bsicamente un diagrama de actividades contiene:

Estados de actividad
Estados de accin
Transiciones
Objetos
Estados de actividad y estados de accin

La representacin de ambos es un rectngulo con las puntas redondeadas, en
cuyo interior se representa bien una actividad o bien una accin. La forma de expresar
tanto una actividad como una accin, no queda impuesta por UML, se podra utilizar
lenguaje natural, una especificacin formal de expresiones, un metalenguaje, etc. La idea
central es la siguiente: Un estado que represente una accin es atmico, lo que significa
que su ejecucin se puede considerar instantnea y no puede ser interrumpida, Al igual
que en el diagrama de estados, el de actividad cuenta con un punto inicial (representado
por un crculo) y uno final (representado como dos crculos concntricos). En la
siguiente figura, podemos ver ejemplos de estados de accin.


58

Figura 46: Estados de Accin

En cambio un estado de actividad, s puede descomponerse en ms sub-
actividades representadas a travs de otros diagramas de actividades. Adems estos
estados s pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los
estados de actividad podemos encontrar otros elementos adicionales como son: acciones
de entrada (entry) y de salida (exit) del estado en cuestin, as como definicin de
submquinas, como podemos ver en la figura siguiente:

Figura 47: Submaquinas
Transiciones

Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de
accin. Esta transicin se produce como resultado de la finalizacin del estado del que
parte el arco dirigido que marca la transicin. Como todo flujo de control debe empezar y
terminar en algn momento, podemos indicar esto utilizando dos disparadores de
inicio y fin tal y como queda reflejado en el ejemplo siguiente.


59

Figura 48: Transiciones
Bifurcaciones

Un flujo de control no tiene porqu ser siempre secuencial, puede presentar
caminos alternativos. Para poder representar dichos caminos alternativos o bifurcacin se
utilizar como smbolo el rombo. Dicha bifurcacin tendr una transicin de entrada y dos
o ms de salida. En cada transicin de salida se colocar una expresin booleana que
ser evaluada una vez al llegar a la bifurcacin, las guardas de la bifurcacin han de ser
excluyentes y contemplar todos los casos ya que de otro modo la ejecucin del flujo de
control quedara interrumpida. Para poder cubrir todas las posibilidades se puede utilizar
la palabra ELSE, para indicar una transicin obligada a un determinado estado cuando el
resto de guardas han fallado. Veamos un ejemplo de bifurcacin.

Figura 49: Bifurcaciones


60
Divisin y unin

No slo existe el flujo secuencial y la bifurcacin, tambin hay algunos casos en
los que se requieren tareas concurrentes. UML representa grficamente el proceso
de divisin, que representa la concurrencia, y el momento de la unin de nuevo al flujo
de control secuencial, por una lnea horizontal ancha. Podemos ver cmo se representa
grficamente.

Figura 50: Divisin y unin
Calles

Cuando se modelan flujos de trabajo de organizaciones, es especialmente til
dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se
denominan calles. Cada calle representa a la parte de la organizacin responsable de las
actividades que aparecen en esa calle. Grficamente quedara como se muestra a
continuacin

Figura 51: Calles

61

CAPITULO 5. MODELADO DINMICO

Leccin 22. Eventos y seales

Un evento es la especificacin de un acontecimiento significativo que ocupa un
lugar en el tiempo y en el espacio. En el contexto de las mquinas de estado, un evento
es la aparicin de un estmulo que puede disparar una transicin de estado. Una
seal es un tipo de evento que representa la especificacin de un estmulo asncrono que
es transmitido entre instancias.

Seales

Una seal representa un objeto con nombre que es enviado (lanzado)
asncronamente por un objeto y recibido (capturado) por otro. El tipo ms comn de
seal interna que se presenta dentro de los lenguajes de programacin son las
excepciones.

Una seal puede enviarse como la accin de una transicin de estado en una
mquina de estados, o como el envo de un mensaje en una interaccin. En UML, la
relacin entre una operacin y los eventos que puede enviar se modela con relacin de
dependencia, estereotipada como send.

Las seales y las excepciones se modelan como clases estereotipadas, se puede
utilizar una dependencia, estereotipada como send para indicar que la operacin enva
una seal particular.

Figura 52: Seales


62
Eventos

Un evento de llamada representa una invocacin de una operacin, un evento
puede disparar una transicin de estado de una mquina de estados. Cuando un objeto
invoca una operacin sobre otro objeto que tiene una mquina de estados, el control
pasa del emisor al receptor, el evento dispara la transicin, la operacin acaba, el
receptor pasa a un nuevo estado y el control regresa al emisor. Grficamente se muestra
al evento con sus parmetros, como el disparador de una transicin de estado.

Figura 53: Eventos
Un evento de tiempo es un evento que representa el paso del tiempo, en UML se
modela un evento de tiempo con la palabra alter seguida de alguna expresin que se
evala para producir algn periodo de tiempo.

Un evento de cambio es un evento que representa un cambio en el estado o el
cumplimiento de alguna condicin, se modela con la palabra when seguida de alguna
expresin booleana.

Figura 54: Un evento de Cambio o de Tiempo
Leccin 23. Mquinas de Estado

Una mquina de estado es un comportamiento que especifica las secuencias de
estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos. Un
Estado es una condicin o situacin en la vida de un objeto durante la cual satisface
alguna condicin, realiza una actividad o espera algn evento. Un evento es la
especificacin de un acontecimiento significativo que ocupa un lugar en el tiempo y el
espacio, es la estimulacin que puede disparar una transicin de estados.

63
Una transicin es una relacin entre dos estados que indica que un objeto que est
en el primer estado realizar ciertas acciones y entrar el segundo estado cuando ocurra
un evento especfico y se satisfagan unas condiciones especficas y una actividad es una
ejecucin no atmica en curso, dentro de una mquina de estados.

Estados

Un estado es una condicin o situacin en la vida de un objeto durante la cual
satisface alguna condicin, realiza una actividad o espera un evento. Un objeto puede
estar en cualquier estado durante una cantidad de tiempo determinado, por ejemplo un
calentador de agua puede estar en cualquiera de los cuatro estados: inactivo, en
preparacin (esperando alcanzar la temperatura adecuada), activo (cuando el calentador
alcanza la temperatura ideal para calentar el agua), y pagado. Un estado tiene varias
partes, nombre, acciones de entrada salida, transiciones internas, subastados y eventos
diferidos. Como se muestra a continuacin un estado se representa con un rectngulo
con las esquinas redondeadas.

Figura 55: Estados

Como se observa en la grfica anterior en la mquina de estados de un objeto se
pueden definir dos estados especiales, en primer lugar el punto inicial que indica el punto
de comienzo por defecto para la mquina de estados o el subestado. En segundo lugar,
el estado final, que indica la ejecucin de la mquina de estado o el estado que lo
contiene ha finalizado


64
Transiciones

Una transicin es una relacin entre dos estados que indica que un objeto que
est en un primer estado , realizar ciertas acciones y entrar en el segundo estado,
cuando ocurra un evento especfico y se satisfagan unas condiciones mnimas,
cuando se produce este cambio de estado. Se dice que la transicin se ha disparado.
Hasta que se dispara la transicin se dice que el objeto est en el estado origen,
despus de dispararse se dice que est en el estado destino.

Figura 56: Transiciones
Una transicin tiene cinco partes, estado origen, evento disparado, condicin de
guarda, accin y estado de destino; una transicin se representa con una lnea continua
dirigida desde el estado origen hacia el destino y una autotransicin es una transicin
cuyos estados origen y destino son los mismos.

Leccin 24. Tiempo y Espacio

Una marca de tiempo denota el instante en el que ocurre un evento, grficamente,
una marca de tiempo es una expresin obtenida a partir del nombre dado al mensaje; una
expresin de tiempo es una expresin que al evaluarse genera un valor de tiempo

65
absoluto o relativo. Una restriccin de tiempo se representa como cualquiera otra
restriccin, es decir, una cadena de texto entre llaves y normalmente conectada a un
electo mediante una relacin de dependencia. La localizacin es la asignacin de un
componente de un nodo. Grficamente, la localizacin se representa como un valor
etiquetado, es decir, una cadena de texto entra llaves colocada debajo del nombre del
elemento, o mediante la inclusin de componentes dentro de nodos.

Figura 57: Tiempo y Espacio

En el grfico anterior se observa la manera como se representa el tiempo y el
siguiente grfico se muestra la localizacin:

Figura 58: Localizacin

66

Leccin 25. Transicin y Accin
Transicin Simple:
Es la relacin entre dos o muchos estados que estn unidos por una flecha,
identificando a un objeto en un estado primario donde se realizara una accin especfica y
que pasara a un segundo estado, cuando ocurra un evento y se cumplan unas
condiciones especficas avanzando as entre los diferentes estados o cerrando el mismo.

Transicin Compleja:
Se da cuando dos o ms estados en una sola transicin y tienen varias fuentes o
destinos. Se representa como una lnea vertical de la cual salen o entran varias lneas de
transicin de estado.
Transicin interna:
Tiene un estado origen pero ningn estado destino. Si una transicin interna tiene
accin, se ejecuta pero no existe cambio de estado.
Accin:
Es cuando una transicin se dispara o se acciona, para que se pueda considerar
como una accin se debe de cumplir con alguna de estas:
Una sentencia de asignacin
Una operacin aritmtica
El envo de una seal a otro objeto
La invocacin de una operacin propia
Asignacin de valores de retorno
Creacin o destruccin de objetos
Una secuencia de acciones simples

Leccin 26. Diagramas de Estado

Es un tipo especial de diagrama y comparte las propiedades comunes al resto de
los diagramas, lo que distingue a un diagrama de estados de los otros tipos de diagramas
es su contenido, normalmente los diagramas de estados contienen:

Estados simples y compuestos
Transiciones, incluyendo eventos y acciones

Observemos un diagrama de estados a continuacin con todos sus componentes


67

Figura 59: Diagrama de estados con todos sus componentes

CAPITULO 6. MODELADO ARQUITECTNICO

Leccin 27. Componentes, despliegue, colaboraciones y patrones
Componentes

Un componente es una parte fsica y reemplazable de un sistema que conforma
un conjunto de interfaces. Grficamente, un componente se representa como un
rectngulo con pestaas, un componente debe tener un nombre que lo distinga del resto
de componentes. El nombre de un componente puede ser simple o de camino que
consta del nombre del componente precedido del nombre del paquete en el que se
encuentra, usualmente un componente se dibuja solamente con su nombre pero se
pueden adornar con valores, etiquetas o con algn comportamiento que indique
sus detalles. Como se muestra en la siguiente figura

Figura 60: Componentes

68

Figura 61: Interfaz

Despliegue

Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un
recurso computacional que generalmente tiene alguna memoria y a menudo
capacidad de procesamiento, grficamente un nodo se representa como un cubo. El
nombre de un componente puede ser simple o de camino que consta del nombre
del componente precedido del nombre del paquete en el que se encuentra,
usualmente un nodo se dibuja solamente con su nombre pero se pueden adornar con
valores, etiquetas o con algn comportamiento que indique sus detalles. Como se
muestra en la siguiente figura.

Figura 62: Despliegue
Colaboraciones

Una colaboracin es una sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los
comportamientos de sus elementos. Una colaboracin es tambin la especificacin de
cmo un elemento tal como un clasificador o un operacin, es realizado mediante un
conjunto de clasificadores y asociaciones que juegan roles especficos utilizados de una
forma especfica, grficamente, una colaboracin se representa como una elipse con
borde discontinua. El nombre de una colaboracin puede ser simple o de camino que

69
consta del nombre de la colaboracin precedido del nombre del paquete en el que se
encuentra, usualmente un nodo se dibuja solamente con su nombre pero se pueden
adornar con valores, etiquetas o con algn comportamiento que indique sus detalles.
Como se muestra en la siguiente figura.

Figura 63: Colaboraciones
Patrones

Un patrn es una solucin comn a un problema comn en un contexto dado. Los
patrones ayudan a visualizar, especificar, construir y documentar los artefactos de un
sistema con gran cantidad de software. Hay dos tipos de patrones, patrones de diseo
(Mecanismos) y frameworks.
Mecanismos

Un mecanismo simplemente muestra un conjunto de abstracciones que colaboran
entre s para llevar a cabo algn comportamiento comn, estos mecanismos se muestran
como colaboraciones simples, ya que solamente dan el nombre a una sociedad de
clases.

Figura 64: Mecanismos
Los mecanismos pueden nombrar una plantilla formada por un conjunto de
abstracciones que colaboran entre s para llevar a cabo algn comportamiento comn, se
representan como colaboraciones parametrizadas que se muestran de forma parecida a
las clases plantilla, observe la siguiente figura

70

Figura 65: Plantilla Formada por un conjunto de abstracciones

Leccin 28. Frameworks

Un frameworks es un patrn arquitectnico que proporciona una plantilla
extensible para aplicaciones dentro de un dominio.

La siguiente figura ilustra un frameworks, llamado AdministradorCiclo entre otras
cosas, este frameworks incluye una colaboracin EventosComunes que contiene un
conjunto de clases evento, junto con un mecanismo GestorDeEventos para procesar
estos eventos de forma cclica. Un cliente que utilice este frameworks tal como un
Marcapasos podra construir sobre las abstracciones en EventosComunes creando
subclases y tambin podra emplear una instancia del mecanismo GestorDeEventos.

Figura 66: Frameworks

71
Leccin 29. Diagramas de Componentes

Lo que distingue a un diagrama de componentes de otros tipos de diagramas es
su contenido. Normalmente contienen componentes, interfaces y relaciones entre ellos. Y
como todos los diagramas, tambin puede contener paquetes utilizados para agrupar
elementos del modelo.

Un diagrama de componentes muestra las organizaciones y dependencias lgicas
entre componentes software, sean stos componentes de cdigo fuente, binarios o
ejecutables. Desde el punto de vista del diagrama de componentes se tienen en
consideracin los requisitos relacionados con la facilidad de desarrollo, la gestin del
software, la reutilizacin, y las restricciones impuestas por los lenguajes de programacin
y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un
diagrama de componentes sern componentes y paquetes.

Dado que los diagramas de componentes muestran los componentes software que
constituyen una parte reusable, sus interfaces, y sus interrelaciones, en muchos
aspectos se puede considerar que un diagrama de componentes es un diagrama de
clases a gran escala. Cada componente en el diagrama debe ser documentado con un
diagrama de componentes ms detallado, un diagrama de clases, o un diagrama de
casos de uso.

Un paquete en un diagrama de componentes representa una divisin fsica del
sistema. Los paquetes se organizan en una jerarqua de capas donde cada capa tiene
una interfaz bien definida. Un ejemplo tpico de una jerarqua en capas de este tipo es:
Interfaz de usuario; Paquetes especficos de la aplicacin; Paquetes reusables;
Mecanismos claves; y Paquetes hardware y del sistema operativo.

Un diagrama de componentes se representa como un grafo de componentes
software unidos por medio de relaciones de dependencia (generalmente de compilacin).
Puede mostrar tambin que un componente software contiene una interfaz, es decir, la
soporta. Un ejemplo se muestra a continuacin

Figura 67: Diagrama de Componentes

72
Leccin 30. Diagramas de Despliegue

Cuando se trata de hardware y el software del sistema, se utiliza los diagramas de
despliegue para razonar sobre la tipologa de procesadores y dispositivos sobre los
que reejecuta el software. Los diagramas de despliegue se utilizan para visualizar los
aspectos estticos de estos nodos f si cos y sus relaciones y para especificar sus
detalles para la construccin, como se muestra a continuacin.

Figura 68: Diagramas de Despliegue
Un diagrama de despliegue es un diagrama que muestra la configuracin de los
nodos que participan en la ejecucin y de los componentes que residen en ellos,
grficamente, un diagrama de despliegue es una coleccin de nodos y arcos.

Leccin 31. Sistemas y modelos

UML proporciona una representacin grfica de los sistemas y los subsistemas,
esta notacin permite visualizar la descompensacin de un sistema en
subsistemas ms pequeos, grficamente, un sistema y un subsistema se representa con
el smbolo de un paquete estereotipado. Observemos su representacin a continuacin.


73

Figura 69: Sistemas y Modelos

Un sistema posiblemente descompuesto en una coleccin de subsistemas, es un
conjunto de elementos organizados para lograr un propsito y descrito por un conjunto
de modelos. Un subsistema es una agrupacin de elementos, algunos de los cuales
constituyen una especificacin del comportamiento ofrecido por otros elementos.

74

TERCERA UNIDAD

PRINCIPIOS DE UML ORIENTADO A OBJETOS

75
UNIDAD 3. PRINCIPIOS DE UML ORIENTADO A OBJETOS

CAPITULO 7. DESARROLLO ORIENTADO A OBJETOS CON UML

Cuando se va a construir un sistema software es necesario conocer un
lenguaje de programacin, pero con eso no basta. Si se quiere que el sistema sea
robusto y sustentable, es necesario que el problema sea analizado y la solucin sea
cuidadosamente diseada. Se debe seguir un proceso robusto, que incluya las
actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear
cmo se realiza el anlisis y el diseo, y cmo se relacionan los productos de
ambos, entonces la construccin de sistemas software va a poder planificar y
repetible. Y la probabilidad de obtener un sistema de mejor calidad al final del
proceso aumenta considerablemente, especialmente cuando se trata de un equipo de
desarrollo formado por varias personas.

La notacin que se usa para los distintos modelos, tal y como se ha dicho
anteriormente, es la proporcionada por UML, que se ha convertido en el estndar de
facto en cuanto a notacin orientada a objetos. El uso de UML permite integrar con
mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros
equipos la documentacin, pues es de esperar que cualquier desarrollador versado en
orientacin a objetos conozca y use UML (o se est planteando su uso).

Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando
en el sistema funcionando, proporcionando as una visin completa y coherente de la
produccin de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo
incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y
a un equipo de desarrollo especficos. El ciclo de vida est dirigido por casos de uso, es
decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. As no
se pierde de vista la motivacin principal que debera estar en cualquier proceso de
construccin de software: el resolver una necesidad del usuario/cliente.

Leccin 32. Visin General

El proceso a seguir para realizar desarrollo orientado a objetos es
complejo, debido a la complejidad que vamos a encontrar al intentar desarrollar
cualquier sistema software de tamao medio-alto. El proceso est formado por una serie
de actividades y subactividades, cuya realizacin se va repitiendo en el tiempo,
aplicadas a distintos elementos.

76
En este apartado se va a presentar una visin general para poder tener una idea
del proceso a alto nivel, y ms adelante se vern los pasos que componen cada fase.

Fase de Planificacin y Especificacin de Requisitos: Planificacin, definicin
de requisitos, construccin de prototipos, etc.

Fase de Construccin del Modelo: La construccin del sistema, las fases dentro
de esta etapa son las siguientes:

Diseo de Alto Nivel: Se analiza el problema a resolver desde la
perspectiva de los usuarios y de las entidades externas que van a solicitar
servicios al sistema.
Diseo de Bajo Nivel: El sistema se especifica en detalle,
describiendo cmo va a funcionar internamente para satisfacer lo
especificado en el Diseo de Alto Nivel.
Implementacin: se lleva lo especificado en el Diseo de Bajo Nivel a un
lenguaje de programacin.
Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el
software funciona correctamente y que satisface lo especificado en la
etapa de Planificacin y Especificacin de Requisitos.
Instalacin: La puesta en marcha del sistema en el entorno previsto de
uso.

De ellas, la fase de Construir es la que va a consumir la mayor parte del
esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar
un enfoque iterativo, tomando en cada iteracin un subconjunto de los requisitos
(agrupados segn casos de uso) y llevndolo a travs del diseo de alto y al de bajo
nivel, para llegar a la implementacin y pruebas.

El sistema va creciendo incrementalmente en cada ciclo. Con esta
aproximacin se consigue disminuir el grado de complejidad que se trata en cada
ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se
puede contrastar con el usuario/cliente.

Leccin 33. Fase de Planificacin y Especificacin de Requisitos

Esta fase se corresponde con la Especificacin de Requisitos tradicional
ampliada con un Borrador de Modelo Conceptual y con una definicin de Casos de Uso
de alto nivel. En esta fase se decidira si se aborda la construccin del sistema
mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente
del paradigma empleado posteriormente.


77
Actividades

Las actividades de esta fase son las siguientes:

Definir el Plan-Borrador.
Crear el Informe de Investigacin Preliminar.
Definir los Requisitos.
Registrar Trminos en el Glosario. (continuado en posteriores fases)
Implementar un Prototipo. (opcional)
Definir Casos de Uso (de alto nivel y esenciales).
Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase
posterior)
Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una
fase posterior)
Refinar el Plan.

El orden no es estricto, lo normal es que las distintas actividades se solapen en
el tiempo. Esto sucede tambin en las actividades de las fases de diseo, que se vern
ms adelante.

De estas actividades no se va a entrar en las que corresponden al campo de la
planificacin de proyectos software, como las correspondientes a creacin de
planes e informes preliminares.

Requisitos

El formato del documento de Especificacin de Requisitos no est definido
en UML, pero se ha incluido este punto para resaltar que la actividad de definicin de
requisitos es un paso clave en la creacin de cualquier producto software. Para
entender y describir los requisitos la tcnica de casos de uso constituye una
valiosa ayuda.

Casos de Uso

Un Caso de Uso es un documento narrativo que describe a los actores utilizando
un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un
sistema. Los casos de uso son requisitos, en particular requisitos funcionales.

Ntese que UML no define un formato para describir un caso de uso. Tan slo
define la manera de representar la relacin entre actores y casos de uso en un
diagrama. Sin embargo, un caso de uso individual no es un diagrama, es un documento
de texto. En la siguiente seccin se define el formato textual para la descripcin de un
caso de uso que se va a utilizar en este documento.


78
Un escenario es un camino concreto a travs del caso de uso, una secuencia
especfica de acciones e interacciones entre los actores y el sistema. Ms
adelante se ver la representacin de los escenarios correspondientes a un caso de
uso por medio de Diagramas de Secuencia.

En un primer momento interesa abordar un caso de uso desde un nivel de
abstraccin alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso
de uso con ms detalle se usa el formato expandido.

Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero
cuando se est usando un cajero automtico:

Caso de Uso: Realizar Reintegro
Actores: Cliente
Tipo: Primario
Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se
identifica y solicita realizar una operacin de reintegro por una cantidad
especfica.

El cajero le da el dinero solicitado tras comprobar que la operacin
puede realizarse. El Cliente coge el dinero y la tarjeta y se va.

En un caso de uso descrito a alto nivel la descripcin es muy general,
normalmente se condensa en dos o tres frases. Es til para comprender el mbito y el
grado de complejidad del sistema.

Casos de Uso Expandidos

Los casos de uso que se consideren los ms importantes y que se considere
que son los que ms influencian al resto, se describen a un nivel ms detallado: en el
formato expandido.

La principal diferencia con un caso de uso de alto nivel est en que incluye un
apartado de Curso Tpico de Eventos, pero tambin incluye otros apartados como se ve
en el siguiente ejemplo:

Caso de Uso: Realizar Reintegro
Actores: Cliente (iniciador)
Propsito: Realizar una operacin de reintegro de una cuenta del banco
Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta,
se identifica y solicita realizar una operacin de reintegro por una cantidad
especfica. El cajero le da el dinero solicitado tras comprobar que la
operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va.


79
Tipo: Primario y esencial
Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el
cajero.
2. Pide la clave de identificacin.
3. Introduce la clave.
4. Presenta las opciones de operaciones disponibles.
5. Selecciona la operacin de Reintegro.
6. Pide la cantidad a retirar.
7. Introduce la cantidad requerida.
8. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera
un recibo.
9. Recoge la tarjeta.
10. Recoge el recibo.
11. Recoge el dinero y se va.

Cursos Alternativas:

Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin.
Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela
la operacin.

Identificacin de Casos de Uso

La identificacin de casos de uso requiere un conocimiento medio acerca de los
requisitos, y se basa en la revisin de los documentos de requisitos existentes, y en el
uso de la tcnica de brainstorming entre los miembros del equipo de desarrollo.

Como gua para la identificacin inicial de casos de uso hay dos mtodos:

a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la organizacin.
2. Para cada actor, identificar los procesos que inicia o en los que participa.

b) Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que responder.
2. Relacionar los eventos con actores y casos de uso.

Ejemplos de casos de uso:
Pedir un producto.
Matricularse en un curso de la facultad.
Comprobar la ortografa de un documento en un procesador de textos.
Comprar un libro en una tienda de libros en Internet


80
Identificacin de los Lmites del Sistema

En la descripcin de un caso de uso se hace referencia en todo momento al
sistema. Para que los casos de uso tengan un significado completo es necesario que
el sistema est definido con precisin.

Al definir los lmites del sistema se establece una diferenciacin entre lo que es
interno y lo que es externo al sistema. El entorno exterior se representa mediante los
actores.

Ejemplos de sistemas son:
El hardware y software de un sistema informtico.
Un departamento de una organizacin.
Una organizacin entera.

Si no se est haciendo reingeniera del proceso de negocio lo ms normal es
escoger como sistema el primero de los ejemplos: el hardware y el software del sistema
que se quiere construir.

Tipos de Casos de Uso

A. Segn su Importancia
Para establecer una primera aproximacin a la priorizacin de casos de uso que
identifiquemos los vamos a distinguir entre:

Primarios: Repr esent an los procesos principales, los ms comunes,
como Realizar Reintegro en el caso del cajero automtico.
Secundarios: Repr esent an casos de uso menores, que van a
necesitarse raramente, tales como Aadir Nueva Operacin.
Opcionales: Representan procesos que pueden no ser abordados en el
presente proyecto.

B. Segn el Grado de Compromiso con el Diseo
En las descripciones que se han visto anteriormente no se han hecho apenas
compromisos con la solucin, se han descrito los casos de uso a un nivel
abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso
definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel
son siempre esenciales por naturaleza, debido a su brevedad y abstraccin.

Por el contrario, un caso de uso real describe concretamente el proceso en
trminos del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta
a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en
las mismas.


81
Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro
en un cajero automtico tenemos la siguiente descripcin del curso tpico.

Eventos: Accin del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la
ranura para tarjetas.
2. Pide el PIN (Personal Identification Number).
3. Introduce el PIN a travs del teclado numrico.
4. Presenta las opciones de operaciones disponibles.
5. etc.

En principio, los casos de uso reales deberan ser creados en la fase de Diseo
de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definicin de
interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del
contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a
pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida. No
hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de
compromiso con el diseo es continuo, y una descripcin especfica de un caso de uso
estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales,
normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de
Uso Esenciales o Reales puros.

Consejos Relativos a Casos de Uso

Nombre: El nombre de un Caso de Uso debera ser un verbo, para
enfatizar que se trata de un proceso, por ejemplo: Comprar Artculos o
Realizar Pedido.
Alternativas equiprobables: Cuando se tiene una alternativa que
ocurre de manera relativamente ocasional, se indica en el apartado
Cursos Alternativos. Pero cuando se tienen distintas opciones, todas ellas
consideradas normales se puede completar el Curso Tpico de Eventos
con secciones adicionales.

Leccin 34. Construccin de los diagramas de casos de Uso

Para construir el Modelo de Casos de Uso en la fase de Planificacin
y especificacin de Requisitos se siguen los siguientes pasos:

1. Despus de listar las funciones del sistema, se definen los lmites del
sistema y se identifican los actores y los casos de uso.
2. Se escriben todos los casos de uso en el formato de alto nivel. Se
categorizan como primarios, secundarios u opcionales.
3. Se dibuja el Diagrama de Casos de Uso.
4. Se detallan relaciones entre casos de uso, en caso de ser necesarias,
y se ilustran tales relaciones en el Diagrama de Casos de Uso.

82
5. Los casos de uso ms crticos, importantes y que conllevan un mayor
riesgo, se describen en el formato expandido esencial. Se deja la
definicin en formato expandido esencial del resto de casos de uso
para cuando sean tratados en posteriores ciclos de desarrollo, para no
tratar toda la complejidad del problema de una sola vez.
6. Se crean casos de uso reales slo cuando:
Descripciones ms detalladas ayudan significativamente a
incrementar la comprensin del problema.
El cliente pide que los procesos se describan de esta forma.
7. Ordenar segn prioridad los casos de uso (este paso se va a
ver a continuacin).

Leccin 35. Planificacin de Casos de Uso segn Ciclos de Desarrollo

La decisin de qu partes del sistema abordar en cada ciclo de desarrollo se va a
tomar basndose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a
asignar la implementacin de uno o ms casos de uso, o versiones simplificadas de
casos de uso. Se asigna una versin simplificada cuando el caso de uso
completo es demasiado complejo para ser tratado en un solo ciclo.

Figura 70: Planificacin de casos de uso segn ciclos de desarrollo
Para tomar la decisin de qu casos de uso se van a tratar primero es necesario
ordenarlos segn prioridad. Las caractersticas de un caso de uso especfico que van a
hacer que un caso de uso tenga una prioridad alta son las siguientes:


83
Impacto significativo en el diseo de la arquitectura. Por ejemplo, si
aporta muchas clases al modelo del dominio o requiere persistencia en los
datos.
Se obtiene una mejor comprensin del diseo con un nivel de
esfuerzo relativamente bajo.
Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo.
Implica bien un trabajo de investigacin significante, o bien el uso de
una tecnologa nueva o arriesgada.
Representa un proceso de gran importancia en la lnea de negocio.
Supone directamente un aumento de beneficios o una disminucin de costos.

Para realizar la clasificacin se puede asignar a cada caso de uso una valoracin
numrica de cada uno de estos puntos, para conseguir una puntuacin total aplicando
pesos a cada apartado.

Caso de Uso de Inicializacin

Prcticamente todos los sistemas van a tener un caso de uso de Inicializacin.
Aunque puede ser que no tenga una prioridad alta en la clasificacin realizada segn el
punto anterior, normalmente va a interesar que sea desarrollado desde el principio.
Inicialmente se desarrolla una versin simplificada, que se va completando en cada ciclo
de desarrollo para satisfacer las necesidades de inicializacin de los casos de uso que
se tratan en dicho ciclo. As se tiene un sistema en cada ciclo de desarrollo que puede
funcionar.

Leccin 36. Fase de Construccin del Modelo

Diseo de Alto Nivel

En la fase de Diseo de Alto Nivel de un ciclo de desarrollo se investiga sobre el
problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se
est tratando. Se intenta llegar a una buena comprensin del problema por parte del
equipo de desarrollo, sin entrar en cmo va a ser la solucin en cuanto a detalles de
implementacin.

Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseo de Alto
Nivel hay una serie de actividades de planificacin. Estas actividades consisten en
actualizar los modelos que se tengan segn lo que se haya implementado, pues
siempre se producen desviaciones entre lo que se ha analizado y diseado y lo que
finalmente se construye. Una vez se tienen los modelos acordes con lo
implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseo de Alto
Nivel.


84
En esta fase se trabaja con los modelos de Diseo de Alto Nivel construidos en
la fase anterior, amplindolos con los conceptos correspondientes a los casos de uso
que se traten en el ciclo de desarrollo actual.

Actividades

Las actividades de la fase de Diseo de Alto Nivel son las siguientes:

1. Definir Casos de Uso Esenciales en formato expandido. (si no estn definidos
)
2. Refinar los Diagramas de Casos de Uso.
3. Refinar el Modelo Conceptual.
4. Refinar el Glosario. (continuado en posteriores fases)
5. Definir los Diagramas de Secuencia del Sistema.
6. Definir Contratos de Operacin.
7. Definir Diagramas de Estados. (opcional)

Modelo Conceptual

Una parte de la investigacin sobre el dominio del problema consiste en
identificar los conceptos que lo conforman. Para representar estos conceptos se va a
usar un Diagrama de Estructura Esttica de UML, al que se va a llamar Modelo
Conceptual. En el Modelo Conceptual se tiene una representacin de conceptos del
mundo real, no de componentes software. El objetivo de la creacin de un Modelo
Conceptual es aumentar la comprensin del problema. Por tanto, a la hora de incluir
conceptos en el modelo, es mejor crear un modelo con muchos conceptos que
quedarse corto y olvidar algn concepto importante.

Identificacin de Conceptos

Para identificar conceptos hay que basarse en el documento de especificacin de
requisitos y en el conocimiento general acerca del dominio del problema. Otro consejo
para identificar conceptos consiste en buscar sustantivos en los documentos de
requisitos o, ms concretamente, en la descripcin de los casos de uso. No es un
mtodo infalible, pero puede servir de gua para empezar.

Para poner nombre a los conceptos se puede usar la analoga con el
cartgrafo, resumida en los siguientes tres puntos:

Usar los nombres existentes en el territorio: hay que usar el vocabulario del
dominio para nombrar conceptos y atributos.
Excluir caractersticas irrelevantes: al igual que el cartgrafo elimina

85
caractersticas no relevantes segn la finalidad del mapa (por ejemplo datos de
poblacin en un mapa de carreteras), un Modelo Conceptual puede excluir
conceptos en el dominio que no son pertinentes en base a los requisitos.
No aadir cosas que no estn ah: si algo no pertenece al dominio del problema no
se aade al modelo.

Creacin del Modelo Conceptual

Para crear el Modelo Conceptual se siguen los siguientes pasos:

Hacer una lista de conceptos candidato usando la Lista de Categoras de
Conceptos y la bsqueda de sustantivos relacionados con los requisitos en
consideracin en este ciclo.
Representarlos en un diagrama.
Aadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que
es necesario conocer.
Aadir los atributos necesarios para contener toda la informacin que se
necesite conocer de cada concepto.

Identificacin de Asociaciones

Una asociacin es una relacin entre conceptos que indica una conexin con
sentido y que es de inters en el conjunto de casos de uso que se est tratando. Se
incluyen en el modelo las asociaciones siguientes:

Asociaciones para las que el conocimiento de la relacin necesita mantenerse por
un cierto perodo de tiempo (asociaciones necesita-conocer).

Asociaciones derivadas de la Lista de Asociaciones

Identificacin de Atributos

Es necesario incorporar al Modelo Conceptual los atributos necesarios para
satisfacer las necesidades de informacin de los casos de uso que se estn
desarrollando en ese momento.

Los atributos deben tomar valor en tipos simples (nmero, texto, etc.), pues los
tipos complejos deberan ser modelados como conceptos y ser relacionados mediante
asociaciones, incluso cuando un valor es de un tipo simple es ms conveniente
representarlo como concepto en las siguientes ocasiones cuando:

Se compone de distintas secciones. Por ejemplo: un nmero de telfono, el
nombre de una persona, etc.

86
Tiene operaciones asociadas, tales como validacin. Ejemplo: nmero nico de
identificacin.
Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.
Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesos,
dlares o en euros.
Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no
es un modelo definitivo, pues a lo largo del desarrollo se va refinando segn se le
aaden conceptos que se haban pasado por alto.

Glosario

En el glosario debe aparecer una descripcin textual de cualquier elemento de
cualquier modelo, para eliminar toda posible ambigedad. Se ordena alfabticamente
por trmino.

CAPITULO 8. DIAGRAMAS DE SECUENCIA DEL SISTEMA

Adems de investigar sobre los conceptos del sistema y su estructura, tambin
es preciso investigar el diseo de alto nivel sobre el comportamiento del sistema, visto
ste como una caja negra. Una parte de la descripcin del comportamiento del
sistema se realiza mediante los Diagramas de Secuencia del Sistema.

En cada caso de uso se muestra una interaccin de actores con el sistema.
En esta interaccin los actores generan eventos, solicitando al sistema operaciones.
Por ejemplo, en el caso de una reserva de un billete de avin, el empleado de la
agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que
supone esa solicitud inicia una operacin en el sistema de reservas.

Los casos de uso representan una interaccin genrica. Una instancia de un
caso de uso se denomina escenario, y muestra una ejecucin real del caso de uso, con
las posibles bifurcaciones y alternativas resueltas de forma particular.

Un Diagrama de Secuencia de Sistema se representa usando la notacin para
diagramas de secuencia de UML estudiadas en la unidad 2 de este mdulo. En l se
muestra para un escenario particular de un caso de uso los eventos que los actores
generan, su orden, y los eventos que se intercambian entre sistemas.

Para cada caso de uso que se est tratando se realiza un diagrama para el curso
tpico de eventos, y adems se realiza un diagrama para los cursos alternativos de
mayor inters. En la siguiente figura se muestra el Diagrama de Secuencia del Sistema
para el caso de uso Realizar Reintegro de un cajero automtico.


87

Figura 71: Diagrama de secuencia del sistema para el caso de uso

Leccin 37. Construccin de un Diagrama de Secuencia del Sistema

Para construir un Diagrama de Secuencia del Sistema para el curso tpico
de eventos de un caso de uso, se siguen los siguientes pasos:

1. Representar el sistema como un objeto con una lnea debajo.
2. Identificar los actores que directamente operan con el sistema, y dibujar
una lnea para cada uno de ellos.
3. Partiendo del texto del curso tpico de eventos del caso de uso, identificar
los eventos (externos) del sistema que cada actor genera y representarlos
en el diagrama.
4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.
los eventos del sistema deberan expresarse en base a la nocin de
operacin que representan, en vez de en base a la interfaz particular.
Por ejemplo, se prefiere finalizarOperacin a presionadaTeclaEnter,
porque captura la finalidad de la operacin sin realizar
compromisos en cuanto a la interfaz usada.


88
Diagramas de Estados

Para modelar el comportamiento del sistema pueden usarse los Diagramas
de estados definidos en la unidad 2 de este mdulo

Se puede aplicar un Diagrama de Estados al comportamiento de los
siguientes elementos:

Una clase software
Un concepto
Un caso de uso

En la fase de Diseo de Alto Nivel slo se hara para los dos ltimos tipos
de elemento, pues una clase software pertenece al Diagrama de Clases de Diseo.

Puesto que el sistema entero puede ser representado por un concepto, tambin
se puede modelar el comportamiento del sistema completo mediante un Diagrama de
Estados.

La utilidad de un Diagrama de Estados en esta fase reside en mostrar la
secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el
sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero automtico si se
est en el transcurso de una operacin.

Para los casos de uso complejos se puede construir un Diagrama de Estados. El
Diagrama de Estados del sistema sera una combinacin de los diagramas de
todos los casos de uso. El uso de Diagramas de Estados es opcional.

Diseo de Bajo Nivel

En la fase de Diseo de Bajo Nivel se crea una solucin a nivel lgico para
satisfacer los requisitos, basndose en el conocimiento reunido en la fase de Diseo de
Alto Nivel. Los modelos ms importantes en esta fase son el Diagrama de Clases de
Diseo y los Diagramas de Interaccin, que se realizan en paralelo y que definen los
elementos que forman parte del sistema orientado a objetos que se va a construir
(clases y objetos) y cmo colaboran entre s para realizar las funciones que se piden al
sistema, segn stas se definieron en los contratos de operaciones del sistema.

Actividades

Las actividades que se realizan en la etapa de Diseo de Bajo Nivel son las
siguientes:

1. Definir los Casos de Uso Reales.

89
2. Definir Informes e Interfaz de Usuario.
3. Refinar la Arquitectura del Sistema.
4. Definir los Diagramas de Interaccin.
5. Definir el Diagrama de Clases de Diseo. (en paralelo con los Diagramas
de Interaccin).
6. Definir el Esquema de Base de Datos. El paso de Refinar la Arquitectura
del Sistema no tiene por qu realizarse en la posicin 3, puede realizarse
antes o despus.

Casos de Uso Reales

Un Caso de Uso Real describe el diseo real del caso de uso segn
una tecnologa concreta de entrada y de salida y su implementacin. Si el caso de uso
implica una interfaz de usuario, el caso de uso real incluir bocetos de las
ventanas y detalles de la interaccin a bajo nivel con los widgets (botn, lista
seleccionable, campo editable, etc.) de la ventana.

Como alternativa a la creacin de los Casos de Uso Reales, el
desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la
fase de implementacin.

Diagramas de Interaccin

Los Diagramas de Interaccin muestran el intercambio de mensajes entre
instancias del modelo de clases para cumplir las post-condiciones establecidas en un
contrato Hay dos clases de Diagramas de Interaccin:

1. Diagramas de Colaboracin.
2. Diagramas de Secuencia.

La notacin en UML para ambos es la definida unidad 2 de este mdulo, los
Diagramas de Colaboracin tienen una mayor expresividad y mayor economa espacial
(una interaccin compleja puede ser muy larga en un Diagrama de Secuencia), sin
embargo en ellos la secuencia de interaccin entre objetos es ms difcil de seguir que
en un Diagrama de Secuencia. Ambos tipos de diagramas expresan la misma
informacin, por lo que se puede usar cualquiera de los dos para expresar la interaccin
entre los objetos del sistema.

La creacin de los Diagramas de Interaccin de un sistema es una de las
actividades ms importantes en el desarrollo orientado a objetos, pues al construirlos se
toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creacin
de estos diagramas, por tanto, debera ocupar un porcentaje significativo en el esfuerzo
dedicado al proyecto entero.


90

Leccin 38. Creacin de los Diagramas de Interaccin

Para crear los Diagramas de Colaboracin o de Secuencia se pueden seguir los
siguientes consejos:

Crear un diagrama separado para cada operacin del sistema en desarrollo en el
ciclo de desarrollo actual. Para cada evento del sistema, hacer un diagrama con l
como mensaje inicial.
Usando los apartados de responsabilidades y de post-condiciones del contrato de
operacin, y la descripcin del caso de uso como punto de partida, disear un
sistema de objetos que interaccionan para llevar a cabo las tareas requeridas.
Si el diagrama se complica, dividirlo en dos diagramas ms pequeos. Para ello se
termina la secuencia de mensajes en un mensaje determinado, y en el segundo
diagrama se comienza con el mensaje que termin el primero. Debe indicarse en el
primer diagrama que el resto de la interaccin se detalla en el segundo.

El comportamiento dinmico del sistema que se describe en un Diagrama de
Interaccin debe ser acorde con la estructura esttica del sistema que se refleja en el
Diagrama de Clases de Diseo. Es aconsejable realizar un Diagrama de Clases de
Diseo borrador antes de comenzar con los Diagramas de Interaccin. La capacidad de
realizar una buena asignacin de responsabilidades a los distintos objetos es una
habilidad clave, y se va adquiriendo segn aumenta la experiencia en el desarrollo
orientado a objetos.

Responsabilidad es como un contrato u obligacin de una clase o tipo. Las
responsabilidades estn ligadas a las obligaciones de un objeto en cuanto a su
comportamiento. Bsicamente, estas responsabilidades pueden ser de tipo Conocer o
de tipo Hacer:

Conocer:
Conocer datos privados encapsulados.
Conocer los objetos relacionados.
Conocer las cosas que puede calcular o derivar.

Hacer:
Hacer algo l mismo.
Iniciar una accin en otros objetos.
Controlar y coordinar actividades en otros objetos.

Por ejemplo, se puede decir que un Recibo es responsable de calcular el total
(tipo hacer), o que una Transaccin es responsable de saber su fecha (tipo conocer).
Las responsabilidades de tipo conocer se pueden inferir normalmente del Modelo
Conceptual y una responsabilidad no es lo mismo que un mtodo, pero los
mtodos se implementan para satisfacer responsabilidades.


91
Leccin 39. Diagrama de Clases de Diseo

Un Diagrama de Clases de Diseo muestra la especificacin para las
clases software de una aplicacin. Incluye la siguiente informacin:

Clases, asociaciones y atributos.
Interfaces, con sus operaciones y constantes.
Mtodos.
Navegabilidad.
Dependencias.

A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseo muestra
definiciones de entidades software ms que conceptos del mundo real. En la siguiente
figura se muestra un ejemplo de Diagrama de Clases de Diseo sencillo.

Figura 72: Diagrama de Clases de Diseo Sencillo
Relaciones de Dependencia Para Representar Visibilidad Entre Clases

Cuando una clase conoce a otra por un medio que no es a travs de un atributo
(una asociacin con la navegabilidad adecuada), entonces es preciso indicar esta
situacin por medio de una dependencia.

92

Un objeto debe conocer a otro para poder llamar a uno de sus mtodos, se dice
entonces que el primer objeto tiene visibilidad sobre el segundo. La visibilidad ms
directa es por medio de atributo, cuando hay una asociacin entre ambas clases y se
puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un
objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el
diagrama de clases mediante relaciones de dependencia:

Parmetro: Cuando a un mtodo de una clase se le pasa como parmetro un objeto
de otra clase, se dice que la primera tiene visibilidad de parmetro sobre la segunda.
La relacin de dependencia entre ambas clases se etiqueta con el estereotipo
<>.

Local: Cuando en un mtodo de una clase se define una variable local que es un
objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda.
La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>.

Global: Cuando hay una variable global en el sistema, instancia de una clase A, y un
mtodo de una clase B llama a un mtodo de A, se dice que la clase B tiene
visibilidad global sobre la clase A. La relacin de dependencia entre ambas clases
se etiqueta con el estereotipo <>.

No es necesario representar la relacin de dependencia entre clases que ya
estn relacionadas por medio de una asociacin, que se trata de una dependencia
ms fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qu
elementos hay que revisar cuando se realiza un cambio en el diseo de un
elemento del sistema.

Solitario: Caso Particular de Visibilidad global

El uso de variables globales no se aconseja por los efectos laterales que se
pueden presentar, pero hay un caso en el que s hay cierta globalidad: las clases que
slo van a tener una instancia. Suele tratarse de clases que se han creado en el Diseo
de Bajo Nivel, que no aparecan en el Modelo Conceptual.

Varias clases de nuestro sistema pueden querer llamar a los mtodos de la nica
instancia de una clase de ese tipo, entonces s se considera que es beneficioso que
se pueda acceder a esa instancia como un valor accesible de forma global.

Una solucin elegante para este caso se implementa mediante un mtodo
de clase para obtener esa nica instancia (los mtodos de clase los permiten algunos
lenguajes orientados a objetos, por ejemplo Java), en vez de definirla directamente
como una variable global. Para indicar que una clase slo va a tener una instancia, se
etiqueta la clase con el estereotipo <>, y las relaciones de dependencia entre las
clases que la usan y se etiquetan tambin <> en vez de <<>>.


93

A continuacin se muestra un ejemplo del cdigo en Java de una clase solitario:

public class Solitario {
// se define la instancia como atributo de clase (static) Solitario static
instancia:= null;
// mtodo de clase que devuelve la instancia public static Solitario dar
instancia () {
if (instancia = = null) {
// si no est creada la instancia la crea instancia:= new Solitario ();
}
return instancia;
}
... // otros mtodos de la clase
}

Cuando otra clase quiere llamar a un mtodo de la instancia incluye el siguiente
cdigo:
Variable Solitario;
Variable = Solitario.dar_instancia();
Variable. Mtodo (); // llamada al mtodo que necesitamos

Leccin 40. Construccin Diagramas de Diseo

Normal mente se tiene una idea de un Diagrama de Clases, con una asignacin
de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases
Borrador, puede seguirse la siguiente estrategia:

Identificar todas las clases participantes en la solucin software. Esto se lleva a cabo
analizando los Diagramas de Interaccin.
Representarlas en un diagrama de clases.
Duplicar los atributos que aparezcan en los conceptos asociados del Modelo
Conceptual.
Aadir los mtodos, segn aparecen en los Diagramas de Interaccin.
Aadir informacin de tipo a los atributos y mtodos.
Aadir las asociaciones necesarias para soportar la visibilidad de atributos requerida.
Aadir flechas de navegabilidad a las asociaciones para indicar la direccin de
visibilidad de los atributos.
Aadir relaciones de dependencia para indicar visibilidad no correspondiente a
atributos.
Algunos de estos pasos se van realizando segn se vayan completando los
Diagramas de Interaccin correspondientes. No existe precedencia entre la realizacin
del Diagrama de Clases de Diseo y los Diagramas de Interaccin. Ambos tipos de
diagramas se realizan en paralelo, y unas veces se trabaja primero ms en el de
clases y otras veces se trabaja primero ms en los de interaccin.


94
No todas las clases que aparecan en el Modelo Conceptual tienen por qu
aparecer en el Diagrama de Diseo. De hecho, tan solo se incluirn aquellas
clases que tengan inters en cuanto a que se les ha asignado algn tipo de
responsabilidad en el diseo del sistema. No hay, por tanto, una transicin directa entre
el Modelo Conceptual y el Diagrama de Clases de Diseo, debido a que ambos se
basan en enfoques completamente distintos: el primero en comprensin de un dominio,
y el segundo en una solucin software.

En el Diagrama de Clases de Diseo se aaden los detalles referentes al
lenguaje de programacin que se vaya a usar. Por ejemplo, los tipos de los atributos y
parmetros se expresarn en el lenguaje de implementacin escogido.

Navegabilidad

La navegabilidad es una propiedad de un rol (un extremo de una asociacin) que
indica que es posible navegar unidireccionalmente a travs de la asociacin, desde
objetos de la clase origen a objetos de la clase destino. Como se vio en la unidad 2 y se
representa en UML mediante una flecha.

La navegabilidad implica visibilidad, normalmente visibilidad por medio de un
atributo en la clase origen. En la implementacin se traducir en la clase origen como
un atributo que sea una referencia a la clase destino.

Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una
funcin, deben ser necesarias, si no es as deben eliminarse. Las situaciones ms
comunes en las que parece que se necesita definir una asociacin con navegabilidad
de A a B son:

A enva un mensaje a B.
A crea una instancia B.
A necesita mantener una conexin con B.

Visibilidad de Atributos y Mtodos

Los atributos y los mtodos deben tener una visibilidad asignada, que puede ser:
+ Visibilidad pblica.
# Visibilidad protegida.
- Visibilidad privada.

Tambin puede ser necesario incluir valores por defecto, y todos los detalles ya
cercanos a la implementacin que sean necesarios para completar el Diagrama de
Clases.

Otros Aspectos en el Diseo del Sistema

95

En los puntos anteriores se ha hablado de decisiones de diseo a un nivel de
granularidad fina, con las clases y objetos como unidades de decisin. En el
diseo de un sistema es necesario tambin tomar decisiones a un nivel ms alto sobre
la descomposicin de un sistema en subsistemas y sobre la arquitectura del sistema
(definicin de sistemas y subsistemas unidad 2). Esta parte del Diseo de Bajo Nivel es
lo que se denomina Diseo del Sistema. Estas decisiones no se toman de forma distinta
en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo
tradicional. Por tanto, no se va a entrar en este documento en cmo se realiza esta
actividad.

Leccin 41. Implementacin y Pruebas

Una vez se tiene completo el Diagrama de Clases de Diseo, se pasa a
la implementacin en el lenguaje de programacin elegido. El programa obtenido se
depura y prueba. Y ya se tiene una parte del sistema funcionando que se puede probar
con los futuros usuarios, e incluso poner en produccin si se ha planificado una
instalacin gradual. Una vez se tiene una versin estable se pasa al siguiente ciclo de
desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo.

Captulo 9. PILARES DE LA ORIENTACIN A OBJETOS

Leccin 42. Abstraccin
Consiste en quitar las propiedades y acciones de un objeto y as dejar las
acciones que sean necesarias. Esto clasifica diferentes tipos de problemas que
requieren diferentes cantidades de informacin aun si estos problemas pertenecen a un
rea en comn. Y se debe tener claro que en cada fase se podran aplicar ms o
menos tributos que en las fases anteriores.

Ignorancia selectiva
La abstraccin nos ayuda a trabajos con temas complejos.
Se enfoca en lo ms importante y por ende ignora lo que no lo es.

Una clase en una abstraccin en la que:
Se enfatiza las caractersticas ms relevantes, por tal razn se suprimen las
dems caractersticas.

Una abstraccin clave solo debe de ser capturada por una y solo unas clase.


96

Leccin 43. Herencia

Partimos diciendo que es la cualidad ms importante de la OOP y que el
concepto de objeto es la instancia de una clase que tiene todas las caractersticas de la
clase de donde provienen, a estas caractersticas representativas se le denomina
herencia, sin importar que atributos o acciones se decida unas en otra clase ya que cada
objeto hereda atributos y operaciones. Tambin podramos definir como superclase la
mayor y las subclases aquellas que estn dentro de la clase mayor.

Recordemos que una clase se simboliza con un rectngulo y el nombre inicia con
mayscula. Igualmente, el nombre de la clase est compuesto por ms de una palabra,
estas deben de ir juntas sin espacio.

Si representamos una clase de tipo escrita, se considera al procedimiento como:
clase con nombre de ruta: ElementosDeportivos::Balon O de tipo grfica.

Figura 73: Clase con Nombre de Ruta
Tipos de herencia
Herencia simple
o Una clase posee una sola superclase directa. El grfico de herencia
es un rbol
Herencia mltiple
o Una clase posee varias superclases directas. El grfico de herencia
no es un rbol

Mecanismos de herencia

Enriquecimiento:
Se aaden variables y/o mtodos
Substitucin:
Un mtodo heredado recibe una nueva definicin (la antigua no es
adecuada al nuevo conjunto de objetos descritos por la superclase
Visibilidad:
Pblica (public)
Privada (private)
Protegida (protected)

97

Figura 74: Herencia

Leccin 44. Polimorfismo
En algunas oportunidades se puede dar la coincidencia de que una accin
presenta el mismo nombre en diferentes clases o en la misma, pero realizar una
funcin diferente.

Se da la posibilidad de que dos mtodos implementen distintas acciones,
identificndose con el mismo nombre, dependiendo del objeto que lo ejecuta o de los
parmetros que recibe, hay que tener la salvedad de que esta se da siempre y cuando el
tipo de parmetro que recibe o el nmero sean diferentes.

Podemos identificar la sobrecarga como tipo especial del polimorfismo y la
invocacin como el resultado al momento de la ejecucin.


98
Figura 75: Polimorfismo
Leccin 45. Encapsulamiento

Cuando hablamos de encapsulamiento nos referimos al ocultamiento del
funcionamiento interno de las diferentes operaciones, de otros objetos y del entorno.
Ejemplo el uso del computador (no es necesario que se sepa cmo funciona ni las
partes que lo componen sino que cumple o satisface la necesidad del usuario, como
jugar, escuchar msica entre otras actividades que podemos realizar).

Figura 76: Encapsulamiento

Se establece que los atributos son propios de un objeto y estos no son visibles
desde otros objetos del entorno.

Los datos y los procedimientos que los manipulan se agrupan en una sola
entidad: el objeto

Figura 77: Estructura de Encapsulamiento

Por qu es til?
Punto de control /
Las respuestas son ms eficientes a los cambios.


99
Leccin 46. Relaciones

Cuando diferentes objetos trabajan en funcin a una meta o propsito y se logra
por medio de la colaboracin entre las partes a travs de las relaciones.

En pocas palabras se define como la conexin entre elementos.

Para diferenciar las distintas relaciones se utilizan una Simbologa con base en
varios tipos de lneas.

Figura 78: Tipos de Lneas que Simbolizan las Relaciones

De los diferentes tipos de relaciones a las que ms se les da importancias son:
las dependencias, las generalizaciones y asociaciones. Tambin existe la relacin
de realizacin.

Dependencias

Es una relacin de significado entre dos elementos, donde cualquier cambio a un
elemento independiente, puede afectar el significado de otro elemento dependiente.

Las dependencias generalmente representan relaciones de uso que manifiestan
que un cambio en la especificacin de un elemento puede afectar a otro que la utiliza,
pero no necesariamente a la inversa.

Las clases o paquetes utilizan en su mayora en su contexto, para indicar que una
clase utiliza a otra como argumento en la asignatura de una operacin.

100

Figura 79: Argumento de Asignatura
Generacionales

Esta hace referencia a la relacin de una sper clase o clase padre con una
subclase o clase hija. La generalizacin significa que los objetos hijos se pueden
emplear en cualquier clase donde pueda aparecer el padre, pero no a la inversa. Es
decir, el hijo puede sustituir al padre, pero el padre no puede sustituir al hijo. Estas son
sus caractersticas:
El hijo hereda atributos y operaciones del padre.
El hijo puede agregar atributos y operaciones.
Puede tener operaciones polimrficas

La generalizacin se llama a veces relacin es-un-tipo-de: un elemento (clase
Animal mamfero) es-un-tipo-de un elemento ms general (clase Animal).

Figura 80: Generacionales


101
Asociaciones

Es una relacin estructural que especifica que los objetos de un elemento estn
conectados con los objetos de otro. Permitiendo a una asociacin entre dos clases se
puede pasar de un objeto de una clase hasta un objeto de otra clase.

Podemos encontrar una caracterstica especial entre las asociaciones y las
dependencias ya que estas pueden ser reflexivas.

Figura 81: Asociaciones
La agregacin es un tipo especial de asociacin, que representa una relacin
estructural entre todo y sus partes. Donde representa Una relacin del tipo Tienen-un
ejemplo, Un AnimalAves Tienen Plumas.

Realizacin

Es una relacin semntica entre clasificadores donde este especifica unas
normas o un reglamento con otro clasificador que garantiza que se cumplir.

Se encuentran relaciones de realizacin: entre interfaces, clases y componentes
que las realizan y entre los casos de uso y las colaboraciones que los realizan.

Si confrontamos las relaciones de la dependencia, la generalizacin y la
asociacin notamos que la realizacin es diferente a las otras relaciones mencionadas y
as poderla trabajar como un tipo aparte de relacin. Pero semnticamente la
realizacin es una mezcla entre dependencia y generalizacin.


102

Figura 82: Realizacin

103
REFERENCIAS BIBLIOGRFICAS

El proceso Unificado de desarrollo de software, Booch Graby, Rumbaugh James,
Jacobson Ivar, Edit Addison Wesly, 2002
Anlisis y Diseo de Sistemas de Informacin, Senn James, Editorial Mc Graw
Hill.
El lenguaje Unificado de Modelado, Booch Graby, Rumbaugh James, Jacobson
Ivar, Edit Addison Wesly, 2002
Anlisis y diseo de Sistemas, Kendall &&Kendall, Editorial Printice Hall.
Certificacin Profesional en Uml, Varios Autores, Saejee Bussiness School, 2009.
epiwiki. (03 de 10 de 2005). Introduccin a UML 2.0. Recuperado el 10 de 05 de
2013, de http://www.epidataconsulting.com/:
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15
IRIS, R. (1995). Red IRIS BSCW. Recuperado el 30 de 05 de 2013, de
http://bscw.rediris.es/pub/bscw.cgi/d673123/Manual de UML.doc
Magma Soft. (19 de Agosto de 2006). Magma Soft. Recuperado el 30 de 05 de
2013, de http://www.magma.com.ni/~jorge/upoli_uml/refs/Resumen_de_UML.doc
monografias.com. (15 de 12 de 2005). Diseo y Modelacin de un Proyecto de
Software Utilizando el lenguaje UML. Recuperado el 30 de 5 de 2013, de
http://www.monografias.com: http://www.monografias.com/trabajos28/proyecto-
uml/proyecto-uml.shtml
Universidad Nacional de Ingeniera. (29 de 12 de 2012). Modelo Dinamico UML.
Recuperado el 20 de 5 de 2013, de http://es.scribd.com:
http://es.scribd.com/doc/106012983/Modelo-Dinamico-UML
Universidad Yacamb. (10 de 2009). Anlisis y Diseo de Sistemas. Recuperado
el 04 de 06 de 2013, de http://www.oocities.org/es:
http://www.oocities.org/es/bcontrerasrodriguez/AnalisisyDisenodeSistemas/foro/forouml.
htm
Universidad Yacamb. (2009). UML (Unified Modeling Lenguaje) . Recuperado el
05 de 06 de 2013, de http://www.oocities.org:
http://www.oocities.org/es/avrrinf/tabd/Foro/Foro_UML.htm
Modelado con UML. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Objetos con UML, Java e Internet (p. [69]). Mexico City: Cengage Learning. Retrieved
from
http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300030&v=2.1&u
=unad&it=r&p=GVRL&sw=w
Modelado y Programacin Orientada a Objetos. (2005). In A. Weitzenfeld,
Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [67]). Mexico
City: Cengage Learning. Retrieved from
Programacin Orientada a Objetos con Java. (2005). In A. Weitzenfeld, Ingeniera
de Software Orientada a Objetos con UML, Java e Internet (p. [129]). Mexico City:
Cengage Learning. Retrieved from

104
Resumen. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos
con UML, Java e Internet (p. 64). Mexico City: Cengage Learning. Retrieved from
Desarrollo de Software Orientado a Objetos. (2005). In A. Weitzenfeld, Ingeniera
de Software Orientada a Objetos con UML, Java e Internet (p. [193]). Mexico City:
Programacin y Desarrollo de Software Para Internet. (2005). In A. Weitzenfeld,
Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [599]). Mexico
City: Cengage Learning. Retrieved from
Desarrollo de Software Para Internet. (2005). In A. Weitzenfeld, Ingeniera de
Software Orientada a Objetos con UML, Java e Internet (p. [629]). Mexico City: Cengage
Learning. Retrieved from
Modelo de Interfaces. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada
a Objetos con UML, Java e Internet (pp. 209-210). Mexico City: Cengage Learning.
Retrieved from
Definicin de Conceptos. (2005). In A. Weitzenfeld, Ingeniera de Software
Orientada a Objetos con UML, Java e Internet (pp. [577]-578). Mexico City: Cengage
Costo y Complejidad del Software. (2005). In A. Weitzenfeld, Ingeniera de
Software Orientada a Objetos con UML, Java e Internet (p. [3]). Mexico City: Cengage
Arquitectura de Clases. (2005). In A. Weitzenfeld, Ingeniera de Software
Orientada a Objetos con UML, Java e Internet (pp. 254-258). Mexico City: Cengage
Mdulos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos
con UML, Java e Internet (pp. 121-127). Mexico City: Cengage Learning. Retrieved from
Modelo de Anlisis. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Objetos con UML, Java e Internet (p. [253]). Mexico City: Cengage Learning. Retrieved
from

105
Diagrama de Clases. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada
Retrieved from
Arquitectura Cliente-Servidor. (2005). In A. Weitzenfeld, Ingeniera de Software
Orientada a Objetos con UML, Java e Internet (pp. [601]-602). Mexico City: Cengage
Objetos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos
con UML, Java e Internet (pp. [69]-72). Mexico City: Cengage Learning. Retrieved from
Clases. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con
UML, Java e Internet (pp. 72-74). Mexico City: Cengage Learning. Retrieved from
Descripcin del Problema. (2005). In A. Weitzenfeld, Ingeniera de Software
Diagramas de Secuencias del Diseo. (2005). In A. Weitzenfeld, Ingeniera de
Software Orientada a Objetos con UML, Java e Internet (pp. 515-521). Mexico City:
Conceptos Bsicos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Objetos con UML, Java e Internet (pp. [21]-24). Mexico City: Cengage Learning.
Retrieved from
Programacin Avanzada. (2005). In A. Weitzenfeld, Ingeniera de Software
Modelos Recientes. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Objetos con UML, Java e Internet (pp. 54-56). Mexico City: Cengage Learning. Retrieved
from
Modelos Clsicos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a

106
Objetos con UML, Java e Internet (pp. 50-54). Mexico City: Cengage Learning. Retrieved
from
Modelo de Requisitos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada
a Objetos con UML, Java e Internet (pp. [195]-197). Mexico City: Cengage Learning.
Retrieved from
Clases Segn Casos de uso. (2005). In A. Weitzenfeld, Ingeniera de Software
HTML. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con
UML, Java e Internet (pp. 602-608). Mexico City: Cengage Learning. Retrieved from
Programacin y Lenguajes Orientados a Objetos. (2005). In A. Weitzenfeld,
Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 25-28).
Mexico City: Cengage Learning. Retrieved from
Atributos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos
con UML, Java e Internet (pp. 74-79). Mexico City: Cengage Learning. Retrieved from
Tipos de Pruebas. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Objetos con UML, Java e Internet (pp. 578-581). Mexico City: Cengage Learning.
Retrieved from
Diccionario de Clases Segn Mdulos. (2005). In A. Weitzenfeld, Ingeniera de
Ensamblados: Agregacin y Composicin. (2005). In A. Weitzenfeld, Ingeniera de
Proceso de Pruebas. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada
Retrieved from

107
Estrategias de Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software
Revisin del Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada
Retrieved from
Lenguajes de Programacin. (2005). In A. Weitzenfeld, Ingeniera de Software
Modelo de Implementacin. (2005). In A. Weitzenfeld, Ingeniera de Software
Modelo de Casos de uso. (2005). In A. Weitzenfeld, Ingeniera de Software
Interfaces Grficas del Usuario. (2005). In A. Weitzenfeld, Ingeniera de Software
Pruebas del Sistema de Reservaciones de Vuelos. (2005). In A. Weitzenfeld,
Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 584-598).
Mexico City: Cengage Learning. Retrieved from
Introduccin a Java. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Retrieved from
Calidad de Software y Modelos de Madurez del Proceso. (2005). In A.
Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp.
56-64). Mexico City: Cengage Learning. Retrieved from

108
Complejidad del Software. (2005). In A. Weitzenfeld, Ingeniera de Software
Programacin Bsica. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada
Retrieved from
Modelo de Proceso. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Retrieved from
Generalizacin y Herencia. (2005). In A. Weitzenfeld, Ingeniera de Software
Modelo del Dominio del Problema. (2005). In A. Weitzenfeld, Ingeniera de
Identificacin de Clases Segn Estereotipos. (2005). In A. Weitzenfeld, Ingeniera
de Software Orientada a Objetos con UML, Java e Internet (pp. 258-270). Mexico City:
Modelo de Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a
Retrieved from
Actores y Casos de uso Para el Sistema de Reservaciones de Vuelos. (2005). In
A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet
(pp. 210-234). Mexico City: Cengage Learning. Retrieved from

Contenido Didáctico Del Curso 200609

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Contenido Didáctico Del Curso 200609

Cargado por

Copyright:

Formatos disponibles

ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA

Contenido Didctico del Curso 200609

También podría gustarte