Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Desarrollo Orientado A Objetos Con UML
Desarrollo Orientado A Objetos Con UML
Desarrollo Orientado a
Objetos con UML
Programacin
C.E.C.yT. Juan de Dios Btz Paredes IPN
www.detodoprogramacion.com
ndice
I UML.................................................................................................................... 1
I.1 Introduccin........................................................................................................................
II NOTACIN UML.............................................................................................. 3
II.1 Modelos..............................................................................................................................
II.2 Elementos Comunes a Todos los Diagramas................................................................
II.2.1 Notas ...........................................................................................................................
II.2.2 Agrupacin de Elementos Mediante Paquetes ...........................................................
II.3 Diagramas de Estructura Esttica ..................................................................................
II.3.1 Clases .........................................................................................................................
II.3.2 Objetos.........................................................................................................................
II.3.3 Asociaciones ...............................................................................................................
II.3.3.1 Nombre de la Asociacin y Direccin....................................................................
II.3.3.2 Multiplicidad...........................................................................................................
II.3.3.3 Roles.....................................................................................................................
II.3.3.4 Agregacin ...........................................................................................................
II.3.3.5 Clases Asociacin.................................................................................................
II.3.3.6 Asociaciones N-Arias ...........................................................................................
II.3.3.7 Navegabilidad........................................................................................................
II.3.4 Herencia...................................................................................................................
II.3.5 Elementos Derivados...............................................................................................
II.4 Diagrama de Casos de Uso .............................................................................................
II.4.1 Elementos ...................................................................................................................
II.4.1.1 Actores..................................................................................................................
II.4.1.2 Casos de Uso .......................................................................................................
II.4.1.3 Relaciones entre Casos de Uso............................................................................
II.5 Diagramas de Interaccin.................................................................................................
II.5.1 Diagrama de Secuencia ..............................................................................................
II.5.2 Diagrama de Colaboracin ..........................................................................................
II.6 Diagrama de Estados....................................................................................................
3
3
3
3
4
4
5
5
5
6
7
7
8
8
9
9
9
10
10
10
10
10
11
11
12
13
www.detodoprogramacion.com
14
14
16
16
16
17
17
17
18
19
19
20
21
22
23
23
23
23
25
25
25
26
27
28
28
28
29
30
30
30
30
31
31
31
32
33
33
33
34
34
IV BIBLIOGRAFA .............................................................................................. 35
www.detodoprogramacion.com
I UML
I.1 Introduccin
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los
elementos que forman un sistema software orientado a objetos. Se ha convertido en el estndar de
facto de la industria, debido a que ha sido concebido por los autores de los tres mtodos ms usados
de orientacin a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron
contratados por la empresa Rational Software Co. para crear una notacin unificada en la que basar
la construccin de sus herramientas CASE. En el proceso de creacin de UML han participado, no
obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o
IBM, as como grupos de analistas y desarrolladores.
www.detodoprogramacion.com
El objetivo principal cuando se empez a gestar UML era posibilitar el intercambio de modelos
entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario
definir una notacin y semntica comn. En la figura 2 se puede ver cul ha sido la evolucin de
UML hasta la creacin de UML 1.1.
Hay que tener en cuenta que el estndar UML no define un proceso de desarrollo especfico, tan
solo se trata de una notacin. En este curso se sigue el proceso propuesto por Craig
Larman[Larman99] que se ajusta a un ciclo de vida evolutivo e incremental dirigido por casos de
uso.
En la parte II de este texto se expone la notacin y semntica de UML, mientras que en la parte III
se presenta el proceso de desarrollo orientado a objetos de Larman, que se sirve de los modelos de
UML que se han visto anteriormente.
www.detodoprogramacion.com
II Notacin UML
En esta parte se ver cmo se representan grficamente en UML los conceptos principales de la
orientacin a objetos.
II.1 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.
Los modelos de UML con los que vamos a trabajar son los siguientes:
www.detodoprogramacion.com
Se pueden indicar relaciones de dependencia entre paquetes mediante una flecha con la lnea a
trazos. Si el paquete A depende del paquete B, entonces ir una flecha de A a B, tal y como se
muestra en la figura 4.
II.3.1 Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el
nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede
representarse de forma esquemtica (plegada), con los detalles como atributos y operaciones
suprimidos, siendo entonces tan solo un rectngulo con el nombre de la clase. En la figura 5 se ve
cmo una misma clase puede representarse a distinto nivel de detalle segn interese, y segn la fase
en la que se est.
www.detodoprogramacion.com
II.3.2 Objetos
Un objeto se representa de la misma forma que una clase. En el compartimento 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.
II.3.3 Asociaciones
Las asociaciones entre dos clases se representan mediante una lnea que las une. La lnea puede
tener una serie de elementos grficos que expresan caractersticas particulares de la asociacin. A
continuacin se vern los ms importantes de entre dichos elementos grficos.
II.3.3.1 Nombre de la Asociacin y Direccin
El nombre de la asociacin 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 en la cual leer el nombre
de la asociacin. En el ejemplo de la figura 7 se puede leer la asociacin como Un objeto de la
clase Perro es mascota de un objeto de la clase Persona.
www.detodoprogramacion.com
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.
II.3.3.2 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).
www.detodoprogramacion.com
II.3.3.3 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.
II.3.3.4 Agregacin
El smbolo de agregacin es un diamante colocado en el extremo en el que est la clase que
representa el todo.
www.detodoprogramacion.com
www.detodoprogramacion.com
II.3.4 Herencia
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.
www.detodoprogramacion.com
II.4.1 Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: Actores, casos de uso y
relaciones entre casos de uso.
II.4.1.1 Actores
Un actor es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se
representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para
actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).
II.4.1.2 Casos de Uso
Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y
el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una
unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una
elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea
especfica que el actor desea llevar a cabo usando el sistema.
II.4.1.3 Relaciones entre Casos de Uso
Entre dos casos de uso puede haber las siguientes relaciones:
www.detodoprogramacion.com
www.detodoprogramacion.com
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. En la figura
16 se representa el Diagrama de Secuencia para la realizacin de una llamada
telefnica.
www.detodoprogramacion.com
www.detodoprogramacion.com
Planificacin, definicin
www.detodoprogramacion.com
de requisitos,
Construccin: La construccin del sistema. Las fases dentro de esta etapa son las siguientes:
- Diseo de Alto Nivel: Se aborda el problema viendo al sistema a construir como una
caja negra, centrndonos en la visin que desde el exterior tienen los actores, esto es, en
los casos de uso. Se analiza el problema construyendo un modelo conceptual.
- Diseo de Bajo Nivel: El sistema definido en la fase anterior se especifica en detalle,
describiendo todas las operaciones que el sistema va a tener que realizar internamente
para satisfacer lo especificado en el diseo de alto nivel.
- Implementacin: Se lleva lo especificado en el diseo 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 evolutivo, tomando en cada
iteracin un subconjunto de los requisitos (agrupados segn casos de uso) y llevndolo a travs del
diseo de alto y bajo nivel hasta la implementacin y pruebas, tal y como se muestra en la figura 19.
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.
www.detodoprogramacion.com
III.2.1 Actividades
Las actividades de esta fase son las siguientes:
1. Definir el Plan-Borrador.
2. Crear el Informe de Investigacin Preliminar.
3. Definir los Requisitos.
4. Registrar Trminos en el Glosario. (continuado en posteriores fases)
5. Implementar un Prototipo. (opcional)
6. Definir Casos de Uso (de alto nivel y esenciales).
7. Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior)
8. Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior)
9. Refinar el Plan.
El orden propuesto es el que parece ms lgico, y en l los pasos 5 y 7 pueden estar en posiciones
distintas. De todos modos, 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 posteriores. 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.
Tan solo se va a ver por encima la actividad de Definicin de Requisitos en cuanto est relacionada
con los Casos de Uso, pues son stos los que van a servir de punto de partida en la fase de Diseo
de Alto nivel.
III.2.2 Requisitos
Un requisito es una descripcin de necesidades o aspiraciones respecto a un producto. El objetivo
principal de la actividad de definicin de requisitos consiste en identificar qu es lo que realmente
se necesita, separar el grano de la paja. Esto se hace en un modo que sirva de comunicacin entre el
cliente y el equipo de desarrollo.
Es aconsejable que un documento de Especificacin de Requisitos tenga los siguientes puntos:
Propsito.
mbito del Sistema, Usuarios.
Funciones del Sistema.
Atributos del Sistema.
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 refinar los requisitos y mejorar la comprensin de los mismos la tcnica de casos de uso
constituye una valiosa ayuda.
www.detodoprogramacion.com
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.
III.2.3.2 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:
www.detodoprogramacion.com
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, eventualmente, da el dinero
solicitado. Devuelve la tarjeta y genera un recibo.
9. Recoge el dinero, el recibo y la tarjeta, y se va.
Cursos Alternativos:
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.
El significado de cada apartado de este formato es como sigue:
Caso de Uso: Nombre del Caso de Uso
Actores: Lista de actores (agentes externos), indicando quin inicia el caso de uso. Los actores
son normalmente roles que un ser humano desempea, pero puede ser cualquier tipo de sistema.
Propsito: Intencin del caso de uso.
Visin General: Repeticin del caso de uso de alto nivel, o un resumen similar.
Tipo: 1. primario, secundario u opcional (descritos ms adelante).
2. esencial o real (descritos ms adelante).
Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los requisitos.
Curso Tpico de Eventos: Descripcin de la interaccin entre los actores y el sistema mediante
las acciones numeradas de cada uno. Describe la secuencia ms comn de eventos, cuando todo
va bien y el proceso se completa satisfactoriamente. En caso de haber alternativas con grado
similar de probabilidad se pueden aadir secciones adicionales a la seccin principal, como se
ver ms adelante.
Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripcin de
la excepcin.
III.2.3.3 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:
www.detodoprogramacion.com
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.
Realizar una llamada telefnica.
www.detodoprogramacion.com
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.
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 de Eventos:
Accin del Actor
1. Este caso de uso empieza cuando un Cliente
introduce una tarjeta en la ranura para tarjetas.
www.detodoprogramacion.com
3. Escoge la operacin A.
4. Presenta las opciones de pago.
5. Selecciona el tipo de pago:
a. Si se paga al contado ver seccin Pago al
Contado.
b. Si se paga con tarjeta ver seccin Pago con
Tarjeta.
6. Genera recibo.
7. Recoge el recibo y se va.
Cursos Alternativos:
Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin.
Seccin: Pago al Contado
Accin del Actor
1. Mete los billetes correspondientes
Cursos Alternativos:
Lnea 3: No hay cambio suficiente. Se cancela la operacin.
Seccin: Pago con Tarjeta
...
www.detodoprogramacion.com
www.detodoprogramacion.com
III.3.1 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. Definir los Diagramas de Secuencia del Sistema.
4. Refinar el Modelo Conceptual.
5. Refinar el Glosario. (continuado en posteriores fases)
6. Definir Contratos de Operacin.
7. Definir Diagramas de Estado. (opcional)
www.detodoprogramacion.com
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 (ver pgina 11). 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. Tan
solo se representan los eventos que entran al sistema, no los que salen del mismo. Tales eventos
entrantes constituyen las operaciones del sistema, las operaciones que son activadas por alguna
accin de un actor.
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.
www.detodoprogramacion.com
Ejemplos
Avin
Terminal_de_Caja
Especificacin_de_Producto
Descripcin_de_Vuelo
Supermercado
www.detodoprogramacion.com
Transacciones
Lneas de una transaccin
Roles de una persona
Contenedores de otras cosas
Cosas en un contenedor
Otros ordenadores o sistemas electromecnicos
externos a
nuestro sistema
Conceptos abstractos
Organizaciones
Eventos
Reglas y polticas
Catlogos
Archivos financieros, de trabajo,
de contratos, de asuntos legales.
Instrumentos y servicios financieros
Manuales, libros
Aeropuerto
Venta, Pago
Reserva
Artculo_de_Venta
Cajero
Piloto
Supermercado, Cesta
Avin
Artculo
Pasajero
Sistema_de_Autorizacin_de_Tarjetas_de
Crdito
Sistema_Controlador_de_Trfico_Areo
Hambre
Departamento_de_Ventas
Compaa_Area_Toto
Venta, Robo, Reunin
Vuelo, Accidente, Aterrizaje
Poltica_de_Devoluciones
Poltica_de_Cancelaciones
Catlogo_de_Productos
Catlogo_de_Piezas
Recibo, Contrato_de_Empleo
Registro_de_Revisiones
Lnea_de_Crdito
Stock
Manual_del_Empleado
Manual_de_Reparaciones
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 del cartgrafo, resumida en los siguientes tres puntos:
Usar lo s 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 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.
III.3.3.2 Creacin del Modelo Conceptual
Para crear el Modelo Conceptual se siguen los siguientes pasos:
1. Hacer una lista de conceptos candidato usando la Lista de Categoras de Conceptos de la Tabla 1
y la bsqueda de sustantivos relacionados con los requisitos en consideracin en este ciclo.
2. Representarlos en un diagrama.
www.detodoprogramacion.com
3. Aadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario
conocer.
4. Aadir los atributos necesarios para contener toda la informacin que se necesite conocer de cada
concepto.
III.3.3.3 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 Tpicas que se muestra en la Tabla 2.
Tabla 2 - Lista de Asociaciones Tpicas.
www.detodoprogramacion.com
III.3.4 Glosario
En el glosario debe aparecer una descripcin textual de cualquier elemento de cualquier modelo,
para eliminar toda posible ambigedad.
Un formato tipo para el glosario es el que se muestra en la Tabla 3.
Tabla 3 - Formato tipo de Glosario.
www.detodoprogramacion.com
Contrato
Nombre:
InsertarTarjeta (nmero_tarjeta: nmero)
Responsabilidades: Comenzar una sesin con el sistema para realizar una operacin. Presentar las
opciones disponibles.
Tipo:
Sistema
Referencias
Funciones del Sistema: R1.2, R1.6, R1.7
Cruzadas:
Casos de Uso:
Reintegro
Notas:
Excepciones:
Si la tarjeta es ilegible, indicar que ha habido un error.
Salida:
Pre-condiciones: No hay una sesin activa.
Post-condiciones: Una nueva Sesin se ha creado. (creacin de instancia).
La Sesin se ha asociado con Cajero. (asociacin formada).
La descripcin de cada apartado de un contrato es como sigue:
www.detodoprogramacion.com
III.3.5.2 Post-condiciones
La parte ms importante de un contrato es aquella en la que se describen las post-condiciones. stas
se basan en el Modelo Conceptual, en los cambios que sufren los elementos del mismo una vez se
ha realizado la operacin. Es mejor usar el tiempo pasado o el pretrito perfecto al redactar una
post-condicin, para enfatizar que se trata de declaraciones sobre un cambio en el estado que ya ha
pasado. Por ejemplo es mejor decir se ha creado una Sesin que decir crear una Sesin.
Cuando se ha creado un objeto, lo normal es que se haya asociado a algn otro objeto ya existente,
porque si no queda aislado del resto del sistema. Por tanto, al escribir las postcondiciones hay que
acordarse de aadir asociaciones a los objetos creados. Olvidar incluir estas asociaciones es el fallo
ms comn cometido al escribir las post-condiciones de un contrato.
www.detodoprogramacion.com
www.detodoprogramacion.com
Hacer:
Hacer algo l mismo.
Iniciar una accin en otros objetos.
Controlar y coordinar actividades en otros objetos.
Por ejemplo, puedo decir que un Recibo es responsable de imprimirse (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.
Una responsabilidad no es lo mismo que un mtodo, pero los mtodos se implementan para
satisfacer responsabilidades.
www.detodoprogramacion.com
www.detodoprogramacion.com
III.4.4.3 Visibilidad
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.
www.detodoprogramacion.com
IV Bibliografa
[Booch99] El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson.
Addison Wesley Iberoamericana, 1999.
[Booch94] Object-Oriented Analysis and Design. G. Booch. Benjamin/Cummings,
1994.
[BJR97] The UML Specification Document. G. Booch, I. Jacobson and J.
Rumbaugh. Rational Software Corp., 1997.
[Jacobson92] Object-Oriented Software Engineering: A Use Case Driven Approach. I.
Jacobson. Addison-Wesley, 1992.
[Larman99] UML y Patrones. C. Larman. Prentice Hall, 1999.
[Rumbaugh91] Object-Oriented Modeling and Design. J. Rumbaugh et al.PrenticeHall,1991.
[UML00] UML Resource Center. Rational Software. http://www.rational.com/uml/
www.detodoprogramacion.com