Académique Documents
Professionnel Documents
Culture Documents
Programa de la asignatura:
Anlisis y diseo orientado a objetos
Unidad 4.
Diseo orientado a objetos con UML (Lenguaje Unificado
de Modelado)
Clave:
Ingeniera:
TSU:
15142313
16142313
ndice
Unidad 4. Diseo orientado a objetos con UML (Lenguaje Unificado de Modelado) .......... 3
Presentacin de la Unidad ................................................................................................. 3
Propsitos de la Unidad ..................................................................................................... 3
Competencia especfica..................................................................................................... 4
4.1. Representacin de objetos y clases con UML ............................................................. 4
4.1.1. Representacin de clases con UML ......................................................................... 4
4.1.2. Representacin de objetos con UML ....................................................................... 5
Actividad 1. Representacin de clases y objetos con UML ................................................ 5
4.2. Diagramas y documentacin para el diseo del software con UML ............................ 6
4.2.1. Casos de uso ........................................................................................................... 7
4.2.2. Escenarios del caso de uso ................................................................................... 11
4.2.3. Diagramas de actividades ...................................................................................... 13
4.2.4. Diagrama secuencial.............................................................................................. 15
4.2.5. Diagrama de clase ................................................................................................. 16
4.2.6. Diagrama de grfico de estado .............................................................................. 18
Actividad 2. Diagramando con UML ................................................................................. 21
Evidencia de aprendizaje. Proyectando un sistema de software con UML y diagrama de
estados ............................................................................................................................ 21
Autorreflexiones ............................................................................................................... 21
Cierre de la Unidad .......................................................................................................... 22
Para saber ms ............................................................................................................... 23
Fuentes de consulta ........................................................................................................ 23
Propsitos de la Unidad
Al trmino de esta unidad logrars:
Realizar un anlisis y un diseo que den forma precisa y detallada a las
especificaciones de clases y objetos, evitando el costo de una mala planeacin en
el comienzo.
Comprender mejor la relacin entre los negocios y los requerimientos del sistema
a disear
Competencia especfica
Aportaciones
Tomada de http://goo.gl/0c35J5
interior. Como se ver ms adelante, el nombre del caso de uso debe reflejar la tarea
especfica que el actor desea llevar a cabo usando el sistema.
Los casos de uso son la parte realmente til del documento, ya que con esta descripcin
tan detallada a travs de imgenes y figuras queda asentado de una manera muy clara la
forma de interactuar entre el sistema y el usuario.
En los casos de uso, la palabra uso se utiliza como sustantivo en lugar de verbo. Un
modelo de caso de uso muestra lo que hace un sistema sin describir cmo lo hace,
muestra como si estuviera un usuario fuera del sistema, mostrando los requerimientos; se
puede hacer usando los objetos y sus interacciones para derivar comportamiento del
objeto, atributos y relaciones.
Como ya se mencion los actores dentro del modelado UML son aquellos que interactan
con el sistema a desarrollar. Las precondiciones son los hechos que se han de cumplir
para que el flujo de evento se pueda llevar a cabo. El flujo de eventos corresponde a la
ejecucin normal y exitosa del caso de uso. Los flujos alternativos son los que permiten
indicar qu es lo que hace el sistema en los casos menos frecuentes e inesperados. Por
ltimo, las poscondiciones son los hechos que se han de cumplir si el flujo de eventos
normal se ha ejecutado correctamente.
El diagrama de caso de uso est formado por:
El actor
Smbolos de caso de uso
Lneas de conexin
Los actores se refieren en una situacin de usuario del sistema; por ejemplo, un actor
podra ser el cliente. Los actores dan o reciben los datos del sistema. Los actores
secundarios ayudan a mantener el sistema en ejecucin o proporcionan ayuda, como las
personas que operan el centro de atencin telefnica, los empleados(as) de ventanilla,
etc.
Un caso de uso ilustra a los desarrolladores un panorama de lo que quieren los usuarios.
No tiene detalles tcnicos o de implementacin. Los casos de uso documentan un solo
evento; se nombran con un verbo y un sustantivo. Las relaciones son el comportamiento y
se usan para conectar a un actor, de las cuales existen cuatro tipos bsicos:
Por el tipo de flechas, se muestran los cuatro tipos: comunica, incluye, extiende y
generaliza.
Al hacer el diagrama del caso de uso hay que pedir todo lo que los usuarios quieren que
el sistema haga para ellos; es decir, mostrar los servicios que se deben proporcionar.
En las fases iniciales sta podra ser una lista de requerimientos que se extiende en las
ltimas fases del anlisis. Usa los siguientes lineamientos para saber cules son estos
requerimientos:
Revisar las especificaciones para establecer los actores.
Identificar los eventos y hacer los casos de uso.
Revisar el caso de uso para determinar el flujo de los datos.
A continuacin se mostrar una figura que muestra un caso de uso de una matriculacin
de un estudiante. Agregar un estudiante incluye verificar la identidad de ste.
El caso de uso Comprar libro de texto extiende el caso de uso Matricular en clase y podra
ser parte de un sistema para matricular a los estudiantes de un curso en lnea.
Pareciera como si el caso de uso Cambiar informacin del estudiante fuera una
caracterstica menor del sistema y no se debiera incluir en el diagrama de caso de uso,
pero debido a que esta informacin cambia con frecuencia, la administracin tiene un
inters sutil en permitir a los estudiantes cambiar su propia informacin personal. El hecho
de que los administradores juzguen esto como importante no slo justifica, sino que exige
que el estudiante pueda cambiar su informacin.
A los estudiantes no se les permitira cambiar su promedio de calificaciones, cuotas a
pagar y otra informacin. Este caso de uso tambin incluye el caso de uso Verificar
identidad, y en esta situacin, significa que el estudiante tiene que introducir una clave de
usuario y contrasea antes de acceder al sistema. Ver informacin del estudiante permite
a los estudiantes visualizar su informacin personal, as como tambin los cursos y
calificaciones. Los diagramas de caso de uso son un buen punto de partida, pero se
necesita una descripcin ms completa de ellos para su documentacin.
En la siguiente imagen se muestran ejemplos de los cuatro tipos de relaciones que se
usan para conectar al actor con el sistema.
10
11
A continuacin se presenta un ejemplo de Gracia (2003), que podra ser el caso de uso
(use case) de escribir un mensaje en un foro:
Nombre:
Autor:
Juan Prez
Fecha:
28/03/2011
Descripcin:
Permite crear un mensaje en el foro de discusin.
Actores:
Usuario de Internet firmado.
Precondiciones:
El usuario debe haberse firmado en el sistema.
Flujo normal:
1. El actor pulsa sobre el botn para crear un nuevo mensaje.
2. El sistema muestra una caja de texto para introducir el ttulo del mensaje y una
zona de mayor tamao para introducir el cuerpo del mensaje.
3. El actor introduce el ttulo del mensaje y el cuerpo del mismo.
4. El sistema comprueba la validez de los datos y los almacena.
Flujo alternativo:
1. El sistema comprueba la validez de los datos, si los datos no son correctos, se
avisa al actor de ello permitindole que los corrija.
Poscondiciones:
El mensaje ha sido almacenado en el sistema.
Ejemplo de caso de uso. Tomado de Gracia (2003).
12
13
Transiciones: las transiciones muestran el paso de un estado a otro, bien sea estado
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
Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software
14
control debe empezar y terminar en algn momento, se puede indicar esto utilizando
dos disparadores de inicio y final.
Transicin
15
En UML una clase es representada por un rectngulo que posee tres divisiones:
16
17
Pblicos (
Privados (
): indican que el atributo slo ser accesible desde dentro de la clase (slo
sus propios mtodos pueden entrar).
Protegidos
): indican que el atributo no ser accesible desde fuera de la clase, pero s
se podr entrar en l por mtodos de la clase adems de las subclases que se deriven.
Los mtodos u operaciones de una clase son la forma en cmo sta interacta con su
entorno, stos pueden tener las caractersticas:
Pblicos (
): indica que el mtodo ser visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
Private (
): indica que el mtodo slo ser accesible desde dentro de la clase (slo
otros mtodos de la clase pueden entrar).
Protegido (
): indica que el mtodo no ser accesible desde fuera de la clase, pero s
se podr entrar en l por mtodos de la clase, adems por los de las subclases que se
deriven.
18
Estado: Identifica un periodo del objeto (no instantneo) en el cual el objeto est
esperando alguna operacin, tiene cierto estado caracterstico o puede recibir
cierto tipo de estmulos.
Eventos: Es una ocurrencia que puede causar la transicin de un estado a otro de
un objeto.
Envo de mensajes: Adems de mostrar la transicin de estados por medio de
eventos, puede representar el momento en el cual se envan mensajes a otros
objetos.
Subestados: Un estado puede descomponerse en subestados, con transiciones
entre ellos y conexiones al nivel superior. Las conexiones se ven a nivel inferior
como estados de inicio o fin, los cuales se suponen conectados a las entradas y
salidas del nivel inmediatamente superior.
Acciones: Es posible especificar la solicitud de un servicio a otro objeto como
consecuencia de la transicin. Se puede especificar el ejecutar una accin como
consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un
evento.
19
Un estado puede componerse de uno o dos niveles: en el primero se coloca el nombre del
estado y si se tiene el segundo nivel, se ponen las acciones de ese estado, y estas
acciones pueden ser de entrada, de transicin o de salida.
Cada vez que hay una accin de entrada es porque fue provocada por un llamado al
objeto. Las de salida pasan cuando ha sido ejecutada la accin que fue solicitada y las de
transicin suceden cuando es llamada una accin, pero sta no causa el cambio hacia
otro estado, por ejemplo:
Donde:
El estado de descolgado sin marcar indica la entrada de tono de llamada, con la
cual se otorga el permiso de ir a la siguiente transicin.
En la transicin entre estados se introduce el dgito.
En el estado marcado parcial se completa la marcacin por medio de una
transicin interna en la cual se introducen los dgitos restantes hasta completar el
nmero telefnico.
Una vez completada la transicin superior se llega al punto final que es la
llamada.
20
Autorreflexiones
Tu Docente en lnea te proporcionar la informacin para realizar tus Autorreflexiones.
21
Cierre de la Unidad
Cierre de unidad
Tomada de http://goo.gl/FrmV5w
Has concluido la unidad 4 del curso. A lo largo de sta se vieron conceptos de diseo
orientado a objetos con UML, cmo se representan los objetos y las clases, adems de
cmo se hacen los diagramas para los casos de uso, escenarios del caso de uso,
diagramas de actividades, diagramas secuenciales, de clase y el grfico de estado.
Es aconsejable que revises nuevamente la unidad en caso de que los temas que se
acaban de mencionar no te sean familiares, o no los recuerdes; de no ser ste tu caso,
has concluido tu curso de Anlisis y diseo orientado a objetos.
FELICIDADES!
22
Para saber ms
Ideas
Tomada de http://goo.gl/2F4jYb
Para saber cmo insertar o crear un dibujo de Visio en otro programa, puedes consultar la
siguiente pgina:
Fuentes de consulta
Libros
Tomada de http://goo.gl/i2K8w7
Alarcn, R. (2005). Diseo orientado a objetos con UML. Madrid: Grupo Eidos.
Figueroa, P. (s. f.). Conceptos bsicos en un diagrama de estados. Canad:
Universidad de Alberta. Recuperado de
http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/estados01.html
23
24