PARTE II

MODELO ESTRUCTURAL
PREPARADO POR EL M.SC. ALDO RAMIRO VALDEZ
ALVARADO
aldo_valdez@hotmail.com
MODELO ESTRUCTURAL
CONTENIDO
1. CLASES.
2. RELACIONES.
3. DIAGRAMAS DE CLASES.
4. PAQUETES.
5. INSTANCIAS.
6. DIAGRAMAS DE OBJETOS.
1. CLASES
Las clases son los elementos mas importantes de un sistema OO.
Una clase es la descripcin de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y
semntica. Una clase puede implementar una o ms interfaces.
Ejemplo.
Informacin Paciente
Nombre paciente
ID
Sexo
Edad
Fecha de Nacimiento
Alta()
Baja()
Modificacin()
Consulta ()
Informe()
NOMBRE
El nombre de la clase es una cadena de texto. Un nombre puede
ser simple o puede ser el nombre de camino, este nombre de
camino es el nombre de clase precedido del paquete. En UML se
puede dibujar la clase solo mostrando el nombre de la clase.
Ejemplo.
1. CLASES
Informacin Paciente Alimentos
java::awt::rectangle
java::io::file
1. CLASES
ATRIBUTOS
Es una abstraccin de un tipo de dato o estado. Es una propiedad
que describe un rango de valores. Una clase puede tener cualquier
numero de atributos o no tener ninguno.
OPERACIONES
Es la implementacin de un servicio para que muestre un
comportamiento. Una operacin cambia el estado o los datos del
objeto. Un operacin es un verbo corto o una expresin verbal
que representa un comportamiento de la clase que lo contiene.
Una clase puede tener cualquier numero de operaciones o
ninguna.
1. CLASES
ORGANIZACIN DE ATRIBUTOS Y OPERACIONES
No es necesario mostrar todos los atributos y operaciones de una
clase, se puede abreviar una clase, es decir, se puede decidir
mostrar algunos o ningn atributo y/o operacin. Para organizar
mejor las listas atributos y operaciones se puede usar estereotipos
para anteponer a cada grupo una categora descriptiva. Ejemplo.
Informacin Paciente
Constructor
Nuevo()
Procesos
Alta()
Baja()
Modificacin()
Consultas
Consulta()
Informe()
1. CLASES
RESPONSABILIDADES
Es un contrato o una obligacin de una clase. Los atributos y
operaciones son las caractersticas por medio de las cuales se lleva
a cabo las responsabilidades de la clase. Se pueden representar al
final del icono de la clase y son en general texto libre. Ejemplo.
Informacin Paciente
Responsabilidades
**maneja la
informacin
relacionada con el
paciente.
1. CLASES
VISIBILIDAD
Uno de los detalles ms importantes que se puede especificar
paro los atributos y operaciones de un clasificador es su
visibilidad.
1.public. Cualquier clasificador externo con visibilidad hacia el
clasificador dado puede utilizar la caracterstica; se especfica
precedindola del signo +.
2.protected. Cualquier descendiente del clasificador puede
utilizar la caracterstica; se especifica precedindola del signo #.
3.private. Slo el propio clasificador puede utilizar
la caracterstica; se especifica precedindola del signo -..
Cuando se especifica la visibilidad de las caractersticas de un
clasificador, normalmente se desea ocultar los detalles de
implementacin y mostrar solo aquellas caractersticas necesarias
para llevar a cabo sus responsabilidades.
ELEMENTOS ABSTRACTOS, RACES, HOJAS Y
POLIMRFICOS.
Ciertas clases son abstractas, es decir, no pueden tener
instancias directas. En UML este tipo de clases se distingue
escribiendo su nombre en cursiva. En contraste una clase
concreta es aqulla que puede tener instancias directas.
Cuando se usa clase, es probable que se desee heredar
caractersticas de otras clases mas generales, y tambin permitir
que otras clases mas especificas hereden caractersticas de ella.
1. CLASES
1. CLASES
Esta es la semntica normal que se tiene con las clases en UML.
Sin embargo se puede especificar que una clase no puede tener
hijos, escribiendo la propiedad leaf bajo el nombre de la clase,
este tipo de clases se llaman clases hoja, tambin se puede
especificar que una clase no puede tener padres, escribiendo la
propiedad root bajo el nombre de la clase, este tipo de clases se
llaman clases raz.
Las operaciones tienen propiedades similares, normalmente una
operacin es polimrfica, lo que significa que se pueden
especificar operaciones con la misma signatura en diferentes
puntos de una jerarqua de clases. Las operaciones de las clases
hija redefinen el comportamiento de las operaciones de las clases
padre. Ejemplo.
1. CLASES
Icono
{root}
origen: Punto
Mostrar()
Icono rectangular
altura: integer
Anchura:integer
BotonOK
{leaf}
Mostrar()
MULTIPLICIDAD
Cuando se utiliza una clase, podemos asumir que puede haber
cualquier numero de instancias de ella, sin embargo, algunas veces
se desea restringir el numero de instancias que una clase puede
tener. Lo mas frecuente es que se desee especificar cero instancias
(en cuyo caso la clase es una clase de utilidad que hace pblicos
solo atributos y operaciones con alcance de clase), una nica
instancia (una clase unitaria o singleton), un numero especifico
de instancias o muchas instancias (el valor por omisin). El
numero de instancias que puede tener una clase es su
multiplicidad. La multiplicidad tambin se aplica a los atributos,
usando una expresin adecuada entre corchetes despus del
nombre.
1. CLASES
1. CLASES
CARACTERSTICAS AVANZADAS DE LOS ATRIBUTOS
Al modelar normalmente se escribe el nombre de cada atributo,
normalmente esto es suficiente para entender el modelo, pero
como se vio anteriormente se puede especificar la visibilidad, el
alcance y la multiplicidad de cada atributo. En su forma completa
la sintaxis de un atributo en UML es:
[visibilidad] nombre [multiplicidad] [:tipo][= valor inicial]
[{propiedades}]
Por ejemplo:
+origen: Punto origen: Punto = (0,0)
Nombre [0 1]: String
Id: Integer {frozen}
1. CLASES
Hay tres propiedades predefinidas que se pueden emplear con los
atributos:
1. changeable. No hay restricciones para modificar el valor del
atributo.
2. addOnly. Para los atributos con multiplicidad mayor que uno,
se pueden aadir valores adicionales, pero una vez creado, un
valor no puede ser eliminado o modificado.
3. frozen. El valor del atributo no se puede modificar tras
inicializar el objeto.
1. CLASES
CARACTERSTICAS AVANZADAS DE LAS
OPERACIONES
Al modelar normalmente se escribe el nombre de cada operacin,
normalmente esto es suficiente para entender el modelo, pero
como se vio anteriormente se puede especificar la visibilidad y el
alcance de cada operacin. An hay ms, tambin se puede
especificar los parmetros, el tipo de retorno, la semntica de
concurrencia y otras propiedades de cada operacin. El nombre
de una operacin junto a sus parmetros (incluido el tipo de
retorno si lo hay) se conoce como signatura de la operacin. UML
distingue entre operacin y mtodo. Una operacin especfica un
servicio que se puede requerir de cualquier objeto de la clase, para
influir en su comportamiento.
1. CLASES
Un mtodo es una implementacin de una operacin. Cada
operacin no abstracta de una clase debe tener un mtodo, el cual
proporciona el algoritmo ejecutable como cuerpo. En su forma
completa la sintaxis de una operacin en UML es:
[visibilidad] nombre [{lista de parmetros}] [:tipo de retorno]
[{propiedades}]
Por ejemplo:
+mostrar
poner (n: Nombre, s: String)
obtenerID (): Integer
reiniciar() {guarded}
En la signatura de una operacin se pueden proporcionar cero o
ms parmetros, que tienen la siguiente sintaxis:
1. CLASES
[direccin] nombre : tipo [= valor por defecto]
Donde direccin puede tomar los siguientes valores:
in. Parmetro de entrada; no se puede modificar.
out. Parmetro de salida; puede modificarse para comunicar
informacin al invocador.
inout. Parmetro de entrada; puede ser modificado.
Adems hay cinco propiedades definidas que se pueden utilizar en
las operaciones.
1. leaf. Operacin hoja, esto significa que la operacin no es
polimrfica y no puede ser redefinida.
2. isQuery. La ejecucin de la operacin no cambia el estado del
sistema. En otras palabras, la operacin es una funcin pura,
sin efectos laterales.
1. CLASES
3. guarded. La semntica e integridad del objeto se garantizan en
presencia de mltiples flujos de control por medio de la
secuenciacin de todas las llamadas a todas las operaciones con
guardas del objeto. En efecto, se puede invocar exactamente
una operacin a un mismo tiempo sobre el objeto, reduciendo
esto a una semntica secuencial.
4. concurrent. La semntica e integridad del objeto se garantizan
en presencia de mltiples flujos de control, tratando la
operacin como atmica. Pueden ocurrir simultneamente
mltiples llamadas desde diversos flujos de control a cualquier
operacin concurrente, y todas pueden ejecutarse
concurrentemente con semntica correcta.
1. CLASES
5. sequential. Los invocadores deben coordinarse para que en el
objeto slo haya un nico flujo al mismo tiempo. En presencia de
mltiples flujos de control, la semntica y la integridad del objeto
no se pueden garantizar.
Las tres ltimas propiedades cubren la semntica de concurrencia
de una operacin. Estas propiedades solo son relevantes en
presencia de objetos activos, procesos o hilos.
CLASES PLANTILLA (TEMPLATES)
Una plantilla es un elemento parametrizado, que permite definir
una familia de clases o de funciones. Una plantilla incluye huecos
para clases, objetos y valores, donde estos huecos sirven como
parmetros para la plantilla.
1. CLASES
ELEMENTOS ESTNDAR
Todos los mecanismos de extensibilidad de UML se aplican a las
clases. Lo ms frecuente es que se utilicen valores etiquetados
para extender las propiedades de la clase (como especificar la
versin de la clase) y estereotipos para especificar nuevos tipos de
componentes. UMl define cuatro estereotipos estndar que se
aplican a las clases:
1. metaclass. Especfica un clasificador cuyos objetos son todos
clases.
2. powertype. Especfica un clasificador cuyos objetos son los
hijos de un padre dado.
3. stereotype. Especfica que el clasificador es un estereotipo que
se puede aplicar a otros elementos.
1. CLASES
4. utility. Especfica una clase cuyos atributos y operaciones
tienen alcance de clase.
2. RELACIONES
Muy pocas clases estn solas, la mayora colaboran con otras de
varias maneras. Dentro del modelado OO existen tres tipos de
relaciones: las dependencias, las generalizaciones y las
asociaciones. En UML la forma en que se conectan las cosas ya
sea lgica o fsicamente se modela usando relaciones.
DEPENDENCIA
Es una relacin de uso que declara que un cambio en la
especificacin de un elemento puede afectar a otro elemento que
la utiliza. Se usan cuando se quiere indicar que un elemento utiliza
a otro, una clase utiliza a otra como argumento en la signatura de
una operacin. Ejemplo.
2. RELACIONES
PelicualVideo
nombre
reproducirEn(c: Canal)
Iniciar()
Para()
Rebobinar()
Canal
Una dependencia simple sin adornos suele bastar para la mayora
de las relaciones de uso que aparecen al modelar, sin embargo si
se quiere modelar ciertos matices UML define 17 estereotipos
agrupados en 6 grupos. De la siguiente manera:
Dependencias de las clases y objetos en los diagramas de clases.
2. RELACIONES
1. bind. Especifica que el origen de la dependencia instancia a la
plantilla destino con los parmetros reales dados.
2. derive. Especifica que el origen puede calcularse a partir del
destino.
3. friend. Especifica que el origen tiene una visibilidad especial en
el destino.
4. instanceOf. Especifica que el origen es una instancia del
clasificador destino.
5. instantiate. Especifica que el origen crea instancias del destino.
6. powertype. Especifica que el destino es un supratipo del
origen; un supratipo es un clasificador cuyos objetos son todos
los hijos de un padre dado.
2. RELACIONES
7. refine. Especifica que el origen est a un grado de abstraccin
mas detallado que el destino.
8. use. Especifica que la semntica del elemento origen depende
de la semntica de la parte pblica del destino
Hay dos estereotipos que se aplican a las dependencias entre
paquetes
1. access. Especifica que el paquete origen tiene permiso para
referenciar elementos del paquete destino.
2. import. Un tipo de acceso que especifica que los contenidos
pblicos del paquete destino entran en el espacio de nombres del
origen, como si hubiesen sido declarados en el origen.
Dos estereotipos se aplican a las relaciones de dependencia entre
casos de uso.
2. RELACIONES
1. extend. Especifica que el caso de uso destino extiende el
comportamiento del origen..
2. include. Especifica que caso de uso origen incorpora
explcitamente el comportamiento de otro caso de uso en la
posicin especificada por el origen.
Hay tres estereotipos que surgen al modelar interacciones entre
objetos.
1. become. Especifica que el destino es el mismo objeto que el
origen, pero en un instante posterior y posiblemente con
diferentes valores, estados o roles.
2. call. Especifica que la operacin origen invoca a la operacin
destino.
3. copy. Especifica que el objeto destino es una copia exacta, pero
independiente del origen.
2. RELACIONES
Un estereotipo que aparece en el contexto de las mquinas de
estados es: send. Especifica que la operacin origen enva el evento
destino.
Por ltimo, hay un estereotipo que aparecer en el contexto de la
organizacin de los elementos de un sistema en subsistemas y
modelos: trace. Especifica que el destino es un antecesor histrico
del origen.
GENERALIZACIN
Es la relacin de un elemento general (superclase, clase padre) y un
caso mas especfico (subclase o clase hija). Es una relacin del tipo
es un tipo de, esto significa que los objetos hijos se pueden
emplear en cualquier lugar que pueda aparecer el padre, pero no a la
inversa, esto en otras palabras significa que el hijo puede sustituir al
padre.
2. RELACIONES
Una clase hija hereda las propiedades de sus clases padres,
especialmente sus atributos y operaciones, a menudo la clase hija
aade atributos y operaciones a los que hereda de sus padres. Una
operacin de la clase hija con el mismo nombre de la clase padre
se conoce como polimorfismo. Una clase puede tener ninguno,
uno o mas padres. Una clase sin padres y uno o mas hijos se
denomina clase raz o clase base. Una clase sin hijos se
denomina clase hoja. Una clase con un nico padre se dice que
utiliza herencia simple, y una clase con varios padres se dice que
utiliza herencia mltiple. Las generalizaciones son muy frecuentes
entre clases e interfaces, y entre paquetes. Ejemplo.
2. RELACIONES
Figura
origen
Mover()
cambiarTamao()
Dibujar()
Rectngulo
esquina: Punto
Crculo
radio: Float
Polgono
puntos: Lista
Dibujar
Cuadrado
2. RELACIONES
Una generalizacin simple sin adornos suele bastar para la
mayora de las relaciones de herencia que aparecen al modelar, sin
embargo si se quiere modelar ciertos matices UML define un
estereotipo y cuatro restricciones que pueden aplicarse a las
generalizaciones.
En primer lugar el estereotipo: implementation. Especifica que
el hijo hereda la implementacin del padre, pero no hace pblicas
ni soporta sus interfaces, y por ello viola la semntica de
sustitucin. Se usar implementation cuando se quiera modelar
la herencia privada.
A continuacin hay cuatro restricciones estndar que se aplican a
las relaciones de generalizacin:
2. RELACIONES
1. complete. Especfica que todos los hijos en la generalizacin
se han especificado en el modelo y no se permiten hijos
adicionales.
2. incomplete. Especfica que no se han especificado todos los
hijos en la generalizacin y que se permiten hijos adicionales.
3. disjoint. Especifica que los objetos del padre no pueden tener
mas de uno de los hijos como tipo.
4. overlapping. Especifica que los objetos del padre pueden
tener mas de uno de los hijos como tipo.
2. RELACIONES
ASOCIACIN
Es una relacin estructural que especfica que los objetos de un
elemento estn conectados con los objetos de otro. Las
asociaciones de objetos de la misma clase se denominan unarias,
entre dos clases binarias, y n arias entre varias clases. Las
asociaciones se utiliarn cuando se quiern representar relaciones
estructurales. Aparte de esta forma bsica hay cuatro adornos que
se aplican a las asociaciones.
Nombre. Una asociacin puede tener un nombre, que describe la
naturaleza de la asociacin. Se puede usar una punta de flecha
para indicar el sentido, para que no exista ambigedad. Ejemplo.
2. RELACIONES
Persona Empresa
Trabaja para
Rol. Cuando una clase participa en una asociacin, tiene un rol
especfico que juega en la asociacin; un rol es simplemente la
cara que la clase de un extremo de la asociacin presenta a la clase
del otro extremo. Ejemplo.
Persona Empresa
empleado patrn
2. RELACIONES
Multiplicidad. A veces es importante sealar cuantos objetos
pueden conectarse a travs de una instancia de una asociacin, a
estos cuantos se denomina multiplicidad de la asociacin. Cuando
se indica una multiplicidad en un extremo de una asociacin, se
esta especificando que, para cada objeto de la clase en el extremo
opuesto debe haber tantos objetos en este extremo. Se puede
indicar una multiplicidad de exactamente uno (1) o tres (3), cero o
uno (0 1), muchos (0 *), o uno o mas (1 *). Ejemplo.
Persona Empresa
empleado patrn
1 * *
2. RELACIONES
Agregacin. Una asociacin normal entre clases representa una
relacin estructural entre iguales, sin embargo a veces se quiere
modelar el Todo Vs. Partes, este tipo de relacin se llama
agregacin. La agregacin es una relacin del tipo tiene un.
Ejemplo.
Empresa
Departamentos
1
*
2. RELACIONES
Para usos avanzados hay otras propiedades que permiten modelar
detalles sutiles, como la navegacin, visibilidad, calificacin y
algunas otras como ser:
Navegacin. Dada una asociacin simple, sin adornos, entre dos
clases, es posible navegar de los objetos de un tipo a los del otro.
A menos que se indique lo contrario. La navegacin a travs de
una asociacin es bidireccional
Usuario Clave
propietario
1 *
2. RELACIONES
Visibilidad. Dada una asociacin entre dos clases, los objetos de
una clase pueden ver y navegar hasta los objetos de la otra, a
menos que se restrinja por medio de un enunciado explicito de
navegacin.
Calificacin. En el contexto de una asociacin, uno de los
esquemas de modelo mas frecuente tiene que ver con el problema
de las bsquedas. Dado un objeto en un extremo de una
asociacin, Cmo identificar un objeto o conjunto de objetos en
el otro extremo?. En UML se modela este esquema con un
calificador, que es un atributo de una asociacin cuyos valores
participan en el conjunto de objetos relacionados con un objeto a
travs de una asociacin. Ejemplo.
2. RELACIONES
MesaDeTrabajo
ArtculoDevuelto
0 1 *
IdTrabajo: int
Especificador de Interfaz. En el contexto de una asociacin,
con otra clase destino, una clase origen puede decidir presentar
slo una parte de su rostro al mundo.
Composicin. La agregacin es un concepto simple con una
semntica bastante profunda. La agregacin simple es
completamente conceptual y no hace ms que distinguir un todo
de una parte. La agregacin simple no cambia el significado de la
navegacin a travs de la asociacin entre el todo y sus partes, ni
liga las vidas del todo y sus partes.
2. RELACIONES
Sin embargo, existe una variacin de la agregacin simple, la
composicin, que es una forma de agregacin con una fuerte
relacin de pertenencia y vidas coincidentes de la parte con el
todo. Las partes con una multiplicidad no fijada pueden crearse
despus de la parte compuesta a la que pertenecen, pero una vez
creadas viven y mueren con ella. Tales partes tambin se pueden
eliminar explcitamente antes de la eliminacin de la parte
compuesta. Ejemplo.
Puerta
Marco
1
*
2. RELACIONES
Clases asociacin. Es una asociacin entre dos clases, la propia
asociacin puede tener propiedades. En UML esto se modelara
con una clase asociacin, la cual es un elemento del modelado
tanto con propiedades de asociacin como de clase. Ejemplo.
Persona Empresa
empleado patrn
Trabajo
Descripcin
fechaContrato
salario
2. RELACIONES
Restricciones. Las propiedades simples y avanzadas que han sido
presentadas hasta ahora son suficientes para la mayora de las
relaciones estructurales que aparecern en el modelado. Sin
embargo UML define cinco restricciones si se quiere mostrar
ciertos matices, que son:
1. implicit. Especifica que la relacin no es manifiesta sino, ms
bien, es slo conceptual.
2. ordered. Especifica que el conjunto de objetos en un extremo
de una asociacin sigue un orden explcito.
3. changeable. Se puede aadir, eliminar y modificar libremente
los enlaces entre los objetos.
4. addOnly. Se puede aadir nuevos enlaces desde un objeto del
otro extremo de la asocicin.
2. RELACIONES
5. frozen. Un enlace una vez aadido desde un objeto del otro
extremo de la asociacin, no se puede modificar ni eliminar.
REALIZACIN
Una realizacin es una relacin semntica entre clasificadores, en
la cual un clasificador especifica un contrato que otro clasificador
garantiza que cumplir. Semnticamente la realizacin es algo as
como una mezcla entre dependencia y generalizacin, y su
notacin es una combinacin de las dos anteriores. La realizacin
se utilizar bajo dos circunstancias: en el contexto de las interfaces
y en el contexto de las colaboraciones. Ejemplo.
2. RELACIONES
interface
AgentedeReglas
aadirRegla()
cambiarRegla()
explicarAccin()
ReglasNegocioPedidos
AgentedeReglas
reglaPedido.dlll
Validar
Usuario
Validacin
Forma Cannica
Forma Abreviada
VOLVER A
INTERFACES
3. DIAGRAMAS DE CLASES
DIAGRAMAS DE CLASES
Representa un conjunto de clases, interfaces y colaboraciones as
como sus relaciones. Se utilizan para modelar el vocabulario del
sistema, as como tambin para modelar colaboraciones o
esquemas. Son la base para modelar diagramas de componentes y
de despliegue. Los diagramas de clases tambin pueden contener
paquetes o subsistemas, los cuales se usan para agrupar los
elementos de un modelo en partes mas grandes. Cuando se
modela la vista de diseo esttica de un sistema, normalmente se
utilizarn los diagramas de clases de una de estas tres formas:
1. Para modelar el vocabulario de un sistema.
2. Para modelar colaboraciones simples.
3. Para modelar un esquema lgico de base de datos.
Ejemplo.
3. DIAGRAMAS DE CLASES
Ventana
Abrir()
Cerrar()
Mover()
Dibujar()
ManejarEvento()
Evento
Control Cuadro de Dialogo Ventana Consola
4. PAQUETES
Un paquete es un mecanismo de propsito general para organizar
elementos en grupos.
Nombre. Un nombre es una cadena de texto, el nombre slo se
denomina nombre simple; y el nombre de camino consta del
nombre del paquete precedido por el nombre del paquete en el
que se encuentra, si se da el caso. Al igual que las clases se puede
dibujar paquetes con adornos que muestran los detalles de lo que
contiene el paquete. Ejemplo.
Reglas de Negocio
+ FormularioDePedido
+ FormularioDeSeguimiento
- Pedido
Cliente
Sensores::Visin
4. PAQUETES
Elementos Contenidos. Un paquete puede contener otros
elementos, incluyendo clases, interfaces, componentes, nodos,
colaboraciones, casos de uso, diagramas e incluso otros paquetes.
Estos elementos se declaran en el paquete, si el paquete se destruye
el elemento se destruye. Cada elemento pertenece exclusivamente a
un nico paquete. Se puede tener elementos del mismo tipo y del
mismo nombre en diferentes paquetes, eso indica que son
diferentes. Se puede tener elementos del mismo nombre en un
mismo paquete lo que indica que los elementos son diferentes. Se
puede tener paquetes dentro de paquetes, se espera como mximo
tres niveles de paquetes anidados.
Visibilidad. Se puede controlar la visibilidad de los elementos
contenidos en un paquete de la misma forma que se lo hace con los
atributos y operaciones de una clase.
4. PAQUETES
Importacin y Exportacin. Se puede tener una clase A dentro
de un paquete y una clase B dentro de otro paquete, teniendo
cada paquete conocimiento del otro. Supongamos que A y B se
declara como pblicas en sus respectivos paquetes, aunque A y B
son pblicas ninguna puede acceder a la otra debido a que sus
paquetes forman un muro opaco. Sin embargo si el paquete de A
importa al paquete de B, A ahora puede ver a B, pero no a la
inversa (relacin univoca). En UML una relacin de importacin
se modela como una dependencia con el estereotipo import. Las
partes que exporta un paquete son slo visibles al contenido de
aquellos paquetes que lo importan explcitamente. Ejemplo.
4. PAQUETES
+ FormularioDePedido
+ FormularioDeSeguimiento
- Pedido
Cliente
+ReglasDePedidos
- GUI::Ventana
Polticas
+Ventana
+Formulario
#GestorEventos
GUI
import
import
4. PAQUETES
Generalizacin. Existen dos tipos de relaciones que pueden
darse entre paquetes, las dependencias de importacin, utilizadas
para importar en un paquete los elementos exportados por otro, y
las generalizaciones, para especificar familias de paquetes.
Todos los mecanismos de extensibilidad de UML se aplican a los
paquetes. UML define cinco estereotipos estndar que se aplican a
los paquetes:
1. facade. Especifica un paquete que es slo una vista de algn
otro paquete.
2. framework. Especifica un paquete que consta principalmente
de patrones.
3. stub. Especifica un paquete que sirve de proxy para el
contenido pblico de otro paquete.
4. PAQUETES
4. subsystem. Especifica un paquete que representa una parte
independiente del sistema completo que se est modelando.
5. system. Especifica un paquete que representa el sistema
completo que se esta modelando.
5. INSTANCIAS
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. Instancia y
objeto son en gran parte sinnimos. Grficamente, una imstancia
se representa subrayando su nombre. Ejemplo.
teclasPulsadas:Cola
:Marco
Abstracciones e instancias. Las instancias no aparecen aisladas,
casi siempre estn ligadas a una abstraccin. Los elementos de
UML que tienen instancias son: clases, componentes, nodos,
casos de uso y asociaciones.
5. INSTANCIAS
Un objeto es algo que ocupa espacio en el mundo real o
conceptual, y al que se le pueden hacer cosas.
UML modela instancias fsicas (clases concretas) y cosas que no
son tan concretas (clases abstractas). Cuando se modelan
instancias, stas se colocan en los diagramas de objetos (si se
desea visualizar sus detalles estructurales) o en diagramas de
interaccin y de actividades (si se desea visualizar su participacin
en situaciones dinmicas).
Nombre. Cada instancia debe tener un nombre que las distinga
de las otras instancias dentro de su contexto. Normalmente un
objeto existe en el contexto de una operacin, un componente o
un nodo. Un nombre es una cadena de texto, llamada nombre
elemental, o puede tener un nombre camino.
5. INSTANCIAS
Un nombre camino el cual consta de la abstraccin precedido por
el nombre del paquete en el que ste se encuentra. Se puede dar
nombres explcitos a los objetos, a pesar, que este nombre slo es
conocido por el computador donde existe, por eso se puede
representar objetos annimos. Cuando se modelan grandes
colecciones de objetos, resulta incomodo representar esta
coleccin, por eso se usan multiobjetos.
:Multimedia::AudioStream
t:Transaccin
unCliente
agente:
:cdigoClave
5. INSTANCIAS
Operaciones. Un objeto no es slo algo que ocupa espacio en el
mundo real, tambin es algo a lo que se le pueden hacer cosas. Si
una clase define una operacin lectura, y se tiene un objeto obj,
entonces la expresin obj.lectura() significa que sobre obj (el
objeto) opera lectura.
Estado. Un objeto tambin tiene un estado, que en este sentido
incluye todas las propiedades (normalmente estticas) del objeto
ms los valores actuales (normalmente dinmicos) de esas
propiedades. Estas propiedades incluyen los atributos del objeto, as
como sus partes agregadas. El estado de un objeto es dinmico, de
forma que al visualizar su estado, realmente se esta especificando el
valor de su estado en un momento dado del tiempo y el espacio,
que puede ser representado en un mismo diagrama de interaccin.
5. INSTANCIAS
El estado puede mostrar una instancia con valores de atributos o
una instancia con un estado explcito. Ejemplo.
miCliente
id: SSN = 432-89-1783
activo = True
c:Telfono
[Esperando Respuesta]
Se puede asociar una mquina de estados con una clase, lo cual es
especialmente til al modelar sistemas dirigidos por eventos o al
modelar el tiempo de vida de una clase. Es estos casos tambin se
puede mostrar el estado de esta mquina para un objeto dado en un
momento dado. Ya que un objeto puede estar en varios estados
simultneamente, tambin se puede mostrar una lista de estados
actuales
5. INSTANCIAS
Elementos estndar. Todos los mecanismos de extensibilidad de
UML se aplican a los objetos. Normalmente no se aplica un
estereotipo directamente a una instancia, ni se le da un valor
etiquetado propio. En vez de eso, el estereotipo y los valores
etiquetados derivan del estereotipo y valores etiquetados de su
abstraccin asociada. UML define dos estereotipos estndar que se
aplican a las relaciones de dependencia entre objetos y clases:
1. instanceOf. Especifica que el objeto origen es un instancia del
clasificador destino.
2. instantiate. Especifica que la clase origen crea instancias de la
clase destino de la dependencia.
Tambin hay dos estereotipos relacionados con los objetos que se
aplican a los mensajes y transiciones:
5. INSTANCIAS
1. become. Especifica que el destino es el mismo objeto que el
origen de la dependencia, pero en un instante posterior y con
valores, estados o roles posiblemente diferentes.
2. copy. Especifica que el objeto destino es una copia exacta del
origen de la dependencia.
UML define una restriccin estndar que se aplica a los objetos:
transient. Especifica que una instancia del rol es creada durante la
ejecucin de la interaccin que lo engloba, pero se destruye antes de
completar la ejecucin.
6. DIAGRAMAS DE OBJETOS
Los diagramas de objetos modelan las instancias de los elementos
contenidos en los diagramas de las clases. Un diagrama de objetos
muestra un conjunto de objetos y sus relaciones en un momento
dado.
Con UML los diagramas de clases se utilizan para visualizar los
aspectos estticos de los bloques de construccin del sistema. Los
diagramas de interaccin se utilizan para ver los aspectos dinmicos
del sistema, y constan de instancias de estos bloques y mensajes
enviados entre ellos. Un diagrama de objetos contiene un conjunto
de instancias de los elementos encontrados en un diagrama de
clases, por tanto un diagrama de objetos representa la vista esttica
de una interaccin, consistiendo en los objetos que colaboran, pero
sin ninguno de los mensajes enviados entre ellos.
6. DIAGRAMAS DE OBJETOS
Propiedades comunes. Comparte las propiedades comunes al
resto de los diagramas (un nombre y un contenido grfico que es
una proyeccin de un modelo).
Contenidos. Normalmente contienen objetos y enlaces, pueden
contener al igual que los otros diagramas notas y restricciones. Los
diagramas de objetos tambin pueden contener paquetes o
subsistemas. A veces se colocan clases detrs de los diagramas de
objetos, especialmente cuando se quiere mostrar la clase que hay
detrs de cada instancia.
Usos comunes. Esta vista sustenta principalmente los requisitos
funcionales de un sistema (los servicios que debe proporcionar el
sistema a sus usuarios finales). Permiten modelar estructuras de
datos estticas. Se usa para modelar estructuras de objetos.
6. DIAGRAMAS DE OBJETOS
Esto implica tomar una instantnea de los objetos de un sistema en
un momento determinado. Un diagrama de objetos representa una
escena esttica dentro de la historia representada por un diagrama
de interaccin. Ejemplo.
P:Persona
nombre = Francisco
ID_empleado = 4362
cargo = Jefe de Ventas
c:Compaia
d1:Departamento
nombre=Ventas
d2:Departamento
nombre=I+Ds
d3:Departamento
nombre=Ventas en USA
:InformacioDeContacto
direccin =Av. Villazon, 2