TECNOLGICO NACIONAL DE MXICO

INSTITUTO TECNOLGICO DE TIJUANA

TOMAS AQUINO

SUBDIRECCIN DEL DEPARTAMENTO DE SISTEMAS Y COMPUTACIN

SEMESTRE AGOSTO DICIEMBRE 2015

UNIDAD II. MODELOS DE CLASES

Y OBJETOS
2.3 Y 2.4 ESTEREOTIPOS E INTERFACES

ANLISIS Y DISEO AVANZADA DE SOFTWARE

MC. ALFREDO LPEZ CHAPARRO
SERIE: SCG-1009SC9B

INTEGRANTES:
o GONZALEZ CASTAEDA OSCAR
o LLARENA VELASCO JESUS
o MOLINA HERNNDEZ ELVIRA
o RODRIGUEZ VAZQUEZ MANUEL
o RUBIO TORRES JORGE
LUNES 21 DE SEPTIEMBRE DEL 2015
TIJUANA, BAJA CALIFORNIA NORTE

INDICE

UNIDAD II. MODELOS DE CLASES Y OBJETOS ..................................................................... 3

2.3 Estereotipos ...................................................................................................................... 3
Caractersticas .................................................................................................................... 3
Los Estereotipos en Diagramas ........................................................................................... 3
2.4 Interfaces ........................................................................................................................ 10
Diferencia entre Clase Abstracta e Interfaz ....................................................................... 10
Representacin ................................................................................................................. 11
REFERENCIAS ........................................................................................................................ 12

2|Pgina

UNIDAD II. MODELOS DE CLASES Y OBJETOS

2.3 Estereotipos
Un estereotipo representa el principal mecanismo de extensin de UML. Un estereotipo extiende
el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construccin que deriven
de los existentes pero sean especficos a un problema.
Caractersticas
Elementos hechos a la medida.
Sirve para disear un sistema a la medida.
Sirve para conservar un modelo o diseo.
Se puede relacionar con otra clase.
Se representa con un nombre entre dos pares de mayor y menor (<< >>).

Los Estereotipos en Diagramas

Estereotipos en Diagrama de clases

El estereotipo sirve para dar una particularidad a la clase, es como declararle un tipo, por tanto,
puede haber unas clases de un estereotipo, otras de otro, etc. Podramos escribir un diagrama
de cualquier tipo con un diagrama de clases usando estereotipos:
Si la lista de atributos y mtodos es larga, se pueden usar estereotipos para organizarla de
manera que sea ms comprensible.

Identificacin de Clases Segn Estereotipos

3|Pgina

Las clases de anlisis deben ser independientes del lenguaje, y se definirn con
estereotipos <<boundary>>, <<control>> y <<entity>>.
Boundary: Interfaces de usuario (pantalla) con sistemas externos.
Control: Especifica que un elemento es un controlador o administrador de algn proceso.
Entity: El elemento constituye un elemento persistente o datos.
El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce
como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro
modelo de anlisis se basa en tres estereotipos bsicos de objetos:
El estereotipo entidad (entity en ingls) para objetos que guarden informacin sobre el
estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Un
ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento
asociados.
El estereotipo interface o borde (boundary en ingls) para objetos que implementen
la presentacin o vista correspondiente a las bordes del sistema hacia el mundo externo, para
todo tipo de actores, no slo usuarios humanos. Un ejemplo de un objeto borde es la
funcionalidad de interface de usuario para insertar o modificar informacin sobre el registro de
usuario.
El estereotipo control (control en ingls) para objetos que implementen el comportamiento
o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos
de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningn otro
tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por
ejemplo, hacer alguna computacin y luego devolver el resultado a un objeto borde. Un ejemplo
tpico de objeto control es analizar el uso del sistema por parte de algn usuario registrado y
presentar tal informacin posteriormente. Este comportamiento no le pertenece a ningn objeto
entidad u objeto borde especfico.
Representaciones

4|Pgina

Ejemplos

Estereotipos en Diagrama de Secuencia

Generalmente, los objetos que participan en una interaccin existen durante todo el tiempo
que dura dicha interaccin. Siendo as, los objetos se sitan en la parte superior y sus
lneas de vida se prolongan a lo largo de todo del diagrama. Sin embargo, tambin pueden
crearse y destruirse objetos durante la interaccin. La creacin y la destruccin de un
objeto se indican mediante mensajes estereotipados con <<create>> y <<destroy>>
respectivamente. Cuando un objeto es creado durante la interaccin, se sita en el
diagrama alineado con el mensaje de creacin y no en la parte superior. La destruccin de
un objeto se muestra dibujando una x grande al final de su lnea vida.
Los rectngulos que aparecen sobre las lneas de vida de los objetos se llaman focos de
control. El foco de control representa el perodo de tiempo durante el cual el objeto est
ejecutando una accin y tiene el control del sistema.

5|Pgina

Estereotipos en Diagrama de Componentes

UML define cinco estereotipos estndar aplicables a los componentes:

executable: especifica un componente que se puede ejecutar en un nodo (archivos
.EXE).
library: especifica una librera de objetos esttica o dinmica (DLL).
table: especifica una tabla de una base de datos.
file: especifica un fichero que puede contener cdigo fuente o datos.
document: especifica un documento.

Generalmente, cuando se utilizan estos estereotipos, no se muestran las interfaces en el

diagrama. En su lugar, se utiliza una notacin simplificada, dibujando las dependencias
directamente del componente que importa la interfaz hacia el componente que la exporta.

Estereotipos en Diagrama de Paquetes

Los paquetes pueden tener relaciones de dependencia y generalizacin. La relacin de

dependencia indica que los elementos de un paquete utilizan o importan los elementos del
paquete del que dependen.
Existen dos estereotipos de la relacin de dependencia entre paquetes, <<import>> y
<<access>>. Ambos especifican que el paquete origen tiene acceso a los elementos del

6|Pgina

paquete destino. La diferencia es que <<import>> aade al espacio de nombres del origen
el contenido del destino, evitando la calificacin de nombres.
Las dependencias de paquetes pueden estar rotuladas con un estereotipo como
<<import>> para describir especficamente la naturaleza de la dependencia. El estereotipo
<<import>> significa que el paquete Recepcin adiciona a s mismo la clase
OrdenDeCompra, permitiendo referencias internas a la clase sin especificar el nombre del
paquete fuente.
Diferente del estereotipo <<access>>, donde debe usarse el calificador de nombre del
paquete, paquete :: clase, porque la clase no se adiciona al paquete receptor.

Una relacin de fusin (merge) entre dos paquetes especifica que el contenido del paquete
origen (receptor) se extiende con el contenido del paquete destino.
Es necesario un mecanismo para fusionar los contenidos de ambos paquetes:
o
o
o

Resuelve los conflictos de nombres mediante especializacin y redefinicin.

Es bastante complicado.
Se define mediante restricciones (precondiciones para realizar la fusin) y
transformaciones (postcondiciones despus de la fusin).

Fsicamente, en el repositorio de modelos no se produce ningn cambio en los paquetes.

7|Pgina

Estereotipos en Diagrama de Despliegue

Uso de estereotipos para distinguir nodos y conexiones. Ejemplo conexiones entre nodos:

Hay dos estereotipos predefinidos de Nodo:

Unidad (device). Recurso computacional fsico sobre el cual pueden ser
desplegados artefactos para su ejecucin.
Entorno de Ejecucin (executionEnvironment). Nodo que ofrece un
entorno para ejecutar un tipo especfico de artefactos ejecutables.

Estereotipos en Diagrama de Casos de Uso

En lo que hemos visto hasta ahora usamos actores y casos de uso, pero se pueden ampliar
los diagramas de casos de uso con estereotipos en las relaciones:
<<extend>>: Representa opcionalidad. Un caso de uso extiende la funcionalidad
de otro. Por ejemplo una transferencia a fecha extiende el caso de uso de una
transferencia en el da. La relacin de extensin se utiliza para modelar la parte de
un caso de uso que puede considerarse como un comportamiento opcional. De esta
forma se separa el comportamiento opcional del obligatorio. Esta relacin se
representa como una dependencia estereotipada como <<extiende>>.
<<include>>: Representa obligatoriedad. Por ejemplo una transferencia o un pago
con tarjeta incluye el caso de uso Debitar dinero de cuenta.
<<uses>>: No especifica ni opcionalidad ni obligatoriedad. Esta relacin significa
que un caso de uso, llamado base, incorpora explcitamente el comportamiento de
otro caso de uso. El caso de uso incorporado nunca se encuentra aislado. Es
instanciado slo como parte de algn caso de uso base que lo utiliza. La relacin de
uso se representa como una dependencia estereotipada con la etiqueta <<usa>>.

8|Pgina

La relacin de uso se utiliza para delegar un comportamiento, comn a varios casos de uso
(los casos de uso base), a un slo caso de uso. En el ejemplo del cajero automtico todos
los casos de uso tienen un comportamiento comn: el cliente debe validarse antes de retirar
dinero, ingresar dinero o consultar el saldo de su cuenta. En lugar de incluir este
comportamiento en cada caso de uso, como hicimos cuando escribamos la especificacin
de Extraer Dinero, podemos agruparlo en un nuevo caso de uso Validar Cliente. Los casos
de uso Extraer Dinero, Ingresar Dinero y Consultar Dinero utilizarn el caso de uso Validar
Cliente. La figura muestra el diagrama de casos de uso del cajero empleando las relaciones
de uso.
La relacin de uso debe indicarse explcitamente en el flujo de eventos de la especificacin
del caso base. Por ejemplo, el flujo de eventos principal de la especificacin del caso de
uso Extraer Dinero debera escribirse de esta forma:

9|Pgina

2.4 Interfaces
Una interfaz es un conjunto de operaciones que especifica cierto aspecto de la
funcionalidad de una clase y es un conjunto de operaciones que una clase presenta a otras.
Los interfaces son mecanismos que permiten a los lenguajes orientados a objetos con
herencia lineal, (lase Java ), acceder a la semntica de los lenguajes orientados a objetos
con herencia mltiple ( lase C++ ).
Diferencia entre Clase Abstracta e Interfaz
Las clases abstractas obligan la herencia a diferencia de las Interfaces que se implementan
en las subclases.
Las clases abstractas pueden definir mtodos y propiedades abstractos, con lo que su
respectiva implementacin en la subclase es obligatoria.
Las interfaces contienen las declaraciones de los mtodos, pero no su implementacin. Al
igual que las clases abstractas, son plantillas de comportamiento que deben ser
implementados por otras clases.

10 | P g i n a

Representacin
En los Diagramas de Clases UML los interfaces se pueden representar de varias formas.

UML define dos tipos de interfaces:

La interfaz proporcionada es aquella que una clase efectivamente implementada.
Las interfaces requeridas son aquellas que necesita una clase para realizar su
cometido. El smbolo utilizado para representarla es un semicrculo.

11 | P g i n a

REFERENCIAS
1. Berzal, F. (s.a.). Clases Abstractas e Interfaces. Octubre 30, 2014, de OOP Sitio web:
http://elvex.ugr.es/decsai/java/pdf/AC-interfaces.pdf
2. Roque, R & Lpez, B. (s.a.). Clases abstractas e Interfaces. Octubre 30, 2014,
Nuevo Laredo Sitio web:
http://www.itnuevolaredo.edu.mx/takeyas/Apuntes/POO/Apuntes/04.%20Clases%20Abstractas%20e%20Interfaces.pdf

de

IT

3. Sparx Systems. (2010). Analysis Stereotypes. Octubre 30, 2014, de Sparx Systems Sitio web:
http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages
/analysisstereotypes.html
4. Guerrero, Z. (2013). Identificacion de Clases Segun Estereotipos. Octubr 30, 2014,
de
Blogspot
Sitio web: http://zeferinogh.blogspot.mx/2013/04/32-identificacion-declases- segun_21.html
5. Yez, E. (2014). Curso UML. Octubre 30, 2015, de Google Docs Sitio web:
https://docs.google.com/document/d/1o3SK41RnK62u3fYzE8ZzoluPeDP0QHVdRBbXpNT2
Co/edit
6. Pari, J. (2012). UML Paquetes. Octubre 30, 2014, de slideshare Sitio web:
http://es.slideshare.net/juliopari/sesion-6-1-uml-paquetes
7. Castro, E. (2008). UML - Lenguaje de Modelamiento Unificado. Octubre 30, 2014,
de
slideshare
Sitio web:
http://es.slideshare.net/ecastrojimenez/uml-lenguaje-demodelamiento- unificado-presentation
8. Ingeniera de software
7ma. Edicin
Ian Sommerville
9. Lenguaje de modelado unificado UML
Jacobson, Booch, Rumbaugh

12 | P g i n a