Estereotipos e Interfaces

7/23/2019 Estereotipos e Interfaces

1/12

UNIDAD II MODELOS DE CLASES

Y OBJETOS

2.3 Y 2.4 ESTEREOTIPOS E INTERFACES

LUNES 21 DE SEPTIEMBRE DEL 2015TIJUANA, BAJA CALIFORNIA NORTE

TECNOLGICO NACIONAL DE MXICOINSTITUTO TECNOLGICO DE TIJUANA

TOMAS AQUINOSUBDIRECCIN DEL DEPARTAMENTO DE SISTEMAS Y COMPUTACIN

SEMESTRE AGOSTODICIEMBRE 2015

ANLISIS Y DISEO AVANZADA DE SOFTWAREMC. ALFREDO LPEZ CHAPARRO

SERIE: SCG-1009SC9B

INTEGRANTES:

o GONZALEZ CASTAEDA OSCARo LLARENA VELASCO JESUS

o MOLINA HERNNDEZ ELVIRAo RODRIGUEZ VAZQUEZ MANUEL

o RUBIO TORRES JORGE


2/122 | P

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


3/123 | P

UNIDAD II. MODELOS DE CLASES Y OBJETOS

2.3 Estereotipos

Un estereotipo representa el principal mecanismo de extensin de UML. Un estereotipo extiendeel 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


4/124 | P

Las clases de anlisis deben ser independientes del lenguaje, y se definirn conestereotipos , y .

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 serde 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 lafuncionalidad de interface de usuario para insertar o modificar informacin sobre el registro de

usuario.

El estereotipo control (controlen 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


5/125 | P g i n

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 y

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 decontrol. El foco de control representa el perodo de tiempo durante el cual el objeto est

ejecutando una accin y tiene el control del sistema.


6/126 | P g i n

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, y

. Ambos especifican que el paquete origen tiene acceso a los elementos del


7/127 | P g i n

paquete destino. La diferencia es que 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

para describir especficamente la naturaleza de la dependencia. El estereotipo

significa que el paquete Recepcin adiciona a s mismo la clase

OrdenDeCompra, permitiendo referencias internas a la clase sin especificar el nombre delpaquete fuente.

Diferente del estereotipo , 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 Resuelve los conflictos de nombres mediante especializacin y redefinicin.

o Es bastante complicado.o 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.


8/128 | P g i n

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:

: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 .

:Representa obligatoriedad. Por ejemplo una transferencia o un pago

con tarjeta incluye el caso de uso Debitar dinero de cuenta.

: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 .


9/129 | P g i n

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:


10/1210 | P g i n

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 conherencia 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 implementanen las subclases.Las clases abstractas pueden definir mtodos y propiedades abstractos, con lo que surespectiva implementacin en la subclase es obligatoria.

Las interfaces contienen las declaraciones de los mtodos, pero no su implementacin. Aligual que las clases abstractas, son plantillas de comportamiento que deben serimplementados por otras clases.


11/1211 | P g i n

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.


12/12|

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, de IT

Nuevo Laredo Sitio web:

http://www.itnuevolaredo.edu.mx/takeyas/Apuntes/POO/Apuntes/04.-

%20Clases%20Abstractas%20e%20Interfaces.pdf

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, deBlogspot Sitio web:http://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-

clases- 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, deslideshare Sitio web: http://es.slideshare.net/ecastrojimenez/uml-lenguaje-de-

modelamiento- unificado-presentation

8. Ingeniera de software7ma. EdicinIan Sommerville

9. Lenguaje de modelado unificado UMLJacobson, Booch, Rumbaugh
http://elvex.ugr.es/decsai/java/pdf/AC-interfaces.pdfhttp://elvex.ugr.es/decsai/java/pdf/AC-interfaces.pdfhttp://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/analysisstereotypes.htmlhttp://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/analysisstereotypes.htmlhttp://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/analysisstereotypes.htmlhttp://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-clases-%20segun_21.htmlhttp://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-clases-%20segun_21.htmlhttp://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-clases-%20segun_21.htmlhttp://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-clases-%20segun_21.htmlhttps://docs.google.com/document/d/1o3SK41RnK62u3fYzE8ZzoluPeDP0QHVdRBbXpNT2Co/edithttps://docs.google.com/document/d/1o3SK41RnK62u3fYzE8ZzoluPeDP0QHVdRBbXpNT2Co/edithttps://docs.google.com/document/d/1o3SK41RnK62u3fYzE8ZzoluPeDP0QHVdRBbXpNT2Co/edithttp://es.slideshare.net/juliopari/sesion-6-1-uml-paqueteshttp://es.slideshare.net/juliopari/sesion-6-1-uml-paqueteshttp://es.slideshare.net/juliopari/sesion-6-1-uml-paqueteshttps://docs.google.com/document/d/1o3SK41RnK62u3fYzE8ZzoluPeDP0QHVdRBbXpNT2Co/edithttps://docs.google.com/document/d/1o3SK41RnK62u3fYzE8ZzoluPeDP0QHVdRBbXpNT2Co/edithttp://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-clases-%20segun_21.htmlhttp://zeferinogh.blogspot.mx/2013/04/32-identificacion-de-clases-%20segun_21.htmlhttp://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/analysisstereotypes.htmlhttp://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/analysisstereotypes.htmlhttp://elvex.ugr.es/decsai/java/pdf/AC-interfaces.pdf

Estereotipos e Interfaces

Documents

Transcript of Estereotipos e Interfaces