Una clase abstracta es una clase de la cual no se pueden definir instancias (u objetos). Por ejemplo:
Una clase abstracta, al no poder ser instanciada, no tiene sentido hasta que una serie de clases la implementan completamente y le dan un significado a todos sus métodos.
Llamaremos concretas a las clases que se pueden instanciar, a las cuales se les puede definir atributos y métodos, para diferenciarlas de las clases abstractas.
A las clases abstractas puras, es decir, a las clases que no contienen ninguna implementación, se les llama interfaces.
Cuando deseemos contar con algún medio para capturar todas las operaciones reutilizables del modelo, debemos usar una interfaz.
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.
La interfaz puede establecer un subconjunto de las operaciones de una clase y no necesariamente todas ellas. Podemos modelar la interfaz igual que una clase, con un símbolo rectangular. La diferencia es que la interfaz no tiene atributos.
Las maneras de distinguir una interfaz de una clase que no muestra sus atributos son usando un estereotipo y especificando la palabra << interfaz >> en el rectángulo, o colocar la letra “I” al principio del nombre de una interfaz.
Gráficamente una interfaz se puede representar de forma expandida como una clase estereotipada con la etiqueta <
La relación entre una clase y una interfaz se conoce como realización. Esta relación se representa con una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que adjunte y apunte a la interfaz.
En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces.
En UML una interfaz es una colección de operaciones que sirven para especificar los servicios de una clase o un componente.
Dependencias
Un estereotipo representa el principal mecanismo de extensión de UML.
Un estereotipo extiende el
vocabulario de UML.
Se representa con
un nombre entre dos pares de mayor y menor (<< >>).
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. Podríamos escribir un
diagrama de cualquier tipo con un diagrama de clases usando estereotipos.
Si la lista de atributos y métodos es larga, se pueden usar estereotipos para organizarla de
de manera que sea más comprensible:
 |
|
Estereotipos
en Diagrama de Casos de Uso
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 día. La relación de
extensión 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 relación 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 relación significa que un caso de uso,
llamado base, incorpora explícitamente el comportamiento de otro caso de uso.
El caso de uso incorporado nunca se encuentra aislado. Es instanciado sólo como
parte de algún caso de uso base que lo utiliza. La relación de uso se representa como una dependencia estereotipada con la etiqueta <<usa>>.
 La
relación de uso se utiliza
para delegar un comportamiento, común a varios casos de uso (los casos
de uso base), a un sólo caso de uso. En el ejemplo del cajero automático todos los casos
de uso tienen un comportamiento común: 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
escribíamos la especificación de Extraer Dinero, podemos agruparlo en un nuevo
caso de uso Validar Cliente. Los casos de uso Extraer Dinero, Ingresar Dinero y
Consultar Dinero utilizarán el caso de uso Validar Cliente. La figura muestra
el diagrama de casos de uso del cajero empleando las relaciones de uso.
La relación de uso debe indicarse
explícitamente en el flujo de eventos de la especificación del caso base. Por
ejemplo, el flujo de eventos principal de la especificación del caso de uso
Extraer Dinero debería escribirse de esta forma:
 Flujo de Eventos Principal
1.
Usa Validar Cliente.
2.
El cajero
solicita la cantidad a retirar.
3.
El cliente
introduce la cantidad a retirar.
4.
El cajero
comprueba si el cliente dispone de esa cantidad en su cuenta y si hay
suficiente dinero en el cajero.
5.
Si el
cliente dispone de esa cantidad y el cajero tiene suficiente dinero, el cajero actualiza
la cuenta del cliente, registra la operación y le entrega el dinero al cliente.
Estereotipos en Diagrama de
Interfaces
Como vimos, a las clases abstractas puras, es decir, a las
clases que no contienen ninguna implementación, se les llama interfaces.
Gráficamente
una interfaz se puede representar de forma expandida como una clase
estereotipada con la etiqueta
<<interface>> o, en su forma abreviada, con una figura en forma de piruleta.
|
En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces. La forma abreviada generalmente se usa en los diagramas de componentes.
Hay dos relaciones que pueden existir entre una clase y una interfaz: la dependencia y la realización.
La dependencia entre una clase y una interfaz tiene el mismo significado y representación que entre dos clases, indica que la clase usa la interfaz.
Para que una interfaz se pueda usar hace falta que otra clase implemente las operaciones que la interfaz especifica. A esta relación entre la interfaz y la clase que la implementa se le llama realización. La realización indica que la clase implementa todas las operaciones de la interfaz. Gráficamente la realización se representa como una generalización con la línea discontinua.
Diferencia
entre Clase Abstracta e Interfaz
Las clases abstractas obligan la
herencia. No
se pueden instanciar, es decir, no se puede crear objetos de ellas.
Las clases abstractas pueden
definir métodos y propiedades abstractos.
Las interfaces contienen las
declaraciones de los métodos, pero no su implementación. Al igual que las clases
abstractas, son plantillas de comportamiento que deben ser implementados por otras clases.
